Thread (5 messages) flat view 5 messages, 2 authors, 2016-06-15

Re: "git reflog expire --all" very slow

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:46:31

Possibly related (same subject, not in this thread)


On Mon, 30 Mar 2009, Linus Torvalds wrote:
This if anything makes things just go slower.

Not much, but some. It went from 36.566s to 38.070s. That may be in the 
noise, I've not done any sensitivity analysis.

I thought you perhaps had a missing "parse_commit()" making the 
reachability thing not work (look_up_gently parses the object, but if it's 
a tag deref_tag() will dereference it until it hits a commit, but never 
parse the commit). But that wasn't it.
Ahhah.

I know why it makes things slower.

The slow case is already inside that whole:

	if (timestamp < cb->cmd->expire_unreachable) {

if-statement, so the thing that slows down is if we hit a commit that is 
_older_ than the expire limit.

But your whole "mark_reachable()" thing only marks things _younger_ than 
that reachable. So you mark exactly the wrong things reachable - you mark 
the ones that we don't even care about.

If I do

	mark_reachable(cb.ref_commit, 0);

instead (to traverse the _whole_ tree, with no regards to date), the time 
shrinks to 1.7s. But of course, that's also wrong.

Qutie frankly, I don't really understand why the logic isn't just

	if (timestamp < cb->cmd->expire_unreachable)
		goto prune; 

why is that reachability so important?

			Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help