login
Header Space

 
 

Re: [PATCH 3/3] Make clear_commit_marks() clean harder

Score:
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Johannes Schindelin <Johannes.Schindelin@...>
Cc: Junio C Hamano <junkio@...>, Rene Scharfe <rene.scharfe@...>, <git@...>
Date: Monday, July 3, 2006 - 1:05 pm

On Mon, 3 Jul 2006, Johannes Schindelin wrote:

No, that's not the problem.

The problem is that if we unconditionally traverse parents - whether 
parsed or not - any merge will basically result in a 2* expansion of the 
working set: we'll traverse all children twice (whether they meet again or 
not).

So the cost of doign unconditional traversals of parents basically 
approaches 2^n, where 'n' is the number of merges.

Now, the fact that we only traverse parents without adding new ones (and 
the decision on whether it is parsed or not is irrelevant - the only 
relevant part being that we don't parse any _new_ ones) means that each 
commit itself is very cheap to traverse, but O(2^n) ends up meaning that 
even a small constant will eventually be pretty big.

The proper fix is _not_ to add the "object->parsed" check (which is silly, 
wrong, and doesn't fix anything at all), but to add a check for whether 
the object has been seen or not.

In the case of clearing flags, you have two choices:

 - _set_ a new flag ("already cleared"). This would work - once - but is 
   obviously pretty bad.

   This is what we do in all the other cases. We usually call the flag 
   SEEN or similar.

 - depend on the flags being "dense", and saying that we depend on the 
   fact that in order for any of the flags to have been set in the first 
   place, at least _one_ of them needs to be set in the path leading up to 
   that commit.

Now, for the specific case of get_merge_bases(), the flags _are_ dense. 
Individual flags may not be (eg the "UNINTERESTING" flag, whatever it's 
called, will not be dense), but the question of "is _any_ of the flags we 
care about set" _will_ be dense.

As such, adding a

	/* Have we already cleared this? */
	if (!(mask & object->flags))
		return;
	object->flags &= ~mask;

to the traversal function will fix the O(m+2^n) behaviour, and turn the 
traversal into O(m+n) (where "n" is the number of merges, and "m" is the 
total number of commits).

		Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
A note on merging conflicts.., Linus Torvalds, (Fri Jun 30, 10:44 pm)
Re: A note on merging conflicts.., Junio C Hamano, (Fri Jun 30, 11:08 pm)
Re: A note on merging conflicts.., Linus Torvalds, (Fri Jun 30, 11:54 pm)
Re: A note on merging conflicts.., Rene Scharfe, (Sat Jul 1, 11:09 am)
Re: A note on merging conflicts.., Junio C Hamano, (Sat Jul 1, 2:37 pm)
Re: A note on merging conflicts.., Rene Scharfe, (Sat Jul 1, 3:29 pm)
Re: A note on merging conflicts.., Linus Torvalds, (Sat Jul 1, 4:04 pm)
Re: A note on merging conflicts.., Junio C Hamano, (Sat Jul 1, 4:07 pm)
Re: A note on merging conflicts.., Junio C Hamano, (Sat Jul 1, 4:14 pm)
Re: [PATCH 4/3] Fold get_merge_bases_clean() into get_merge_..., Johannes Schindelin, (Sun Jul 2, 5:56 am)
[PATCH 3/3] Make clear_commit_marks() clean harder, Rene Scharfe, (Sat Jul 1, 7:29 pm)
Re: [PATCH 3/3] Make clear_commit_marks() clean harder, Junio C Hamano, (Mon Jul 3, 5:32 am)
Re: [PATCH 3/3] Make clear_commit_marks() clean harder, Johannes Schindelin, (Mon Jul 3, 9:56 am)
Re: [PATCH 3/3] Make clear_commit_marks() clean harder, Junio C Hamano, (Mon Jul 3, 3:47 pm)
Re: [PATCH 3/3] Make clear_commit_marks() clean harder, Johannes Schindelin, (Mon Jul 3, 5:12 pm)
Re: [PATCH 3/3] Make clear_commit_marks() clean harder, Linus Torvalds, (Mon Jul 3, 6:55 pm)
Re: [PATCH 3/3] Make clear_commit_marks() clean harder, Johannes Schindelin, (Tue Jul 4, 3:53 am)
Re: [PATCH 3/3] Make clear_commit_marks() clean harder, Junio C Hamano, (Tue Jul 4, 4:20 am)
Re: [PATCH 3/3] Make clear_commit_marks() clean harder, Linus Torvalds, (Mon Jul 3, 1:05 pm)
Re: [PATCH 3/3] Make clear_commit_marks() clean harder, Johannes Schindelin, (Mon Jul 3, 5:08 pm)
[PATCH 2/3] Add '...' operator for revisions, Rene Scharfe, (Sat Jul 1, 7:29 pm)
[PATCH 1/3] Add get_merge_bases_clean(), Rene Scharfe, (Sat Jul 1, 7:29 pm)
Re: [PATCH 1/3] Add get_merge_bases_clean(), Johannes Schindelin, (Sat Jul 1, 7:43 pm)
Re: A note on merging conflicts.., Junio C Hamano, (Sat Jul 1, 3:56 pm)
Re: A note on merging conflicts.., Johannes Schindelin, (Sat Jul 1, 7:01 pm)
Re: A note on merging conflicts.., J. Bruce Fields, (Sat Jul 1, 2:01 pm)
Re: A note on merging conflicts.., Linus Torvalds, (Sat Jul 1, 2:20 pm)
Re: A note on merging conflicts.., Daniel Barkalow, (Sat Jul 1, 6:24 pm)
Re: A note on merging conflicts.., Linus Torvalds, (Sat Jul 1, 6:57 pm)
Re: A note on merging conflicts.., Daniel Barkalow, (Sat Jul 1, 7:25 pm)
Re: A note on merging conflicts.., Linus Torvalds, (Sat Jul 1, 8:08 pm)
Re: A note on merging conflicts.., Daniel Barkalow, (Sat Jul 1, 7:45 pm)
Re: A note on merging conflicts.., Rene Scharfe, (Sun Jul 2, 7:31 am)
Re: A note on merging conflicts.., Daniel Barkalow, (Sun Jul 2, 5:42 pm)
Re: A note on merging conflicts.., Linus Torvalds, (Sat Jul 1, 12:25 pm)
Re: A note on merging conflicts.., Rene Scharfe, (Sat Jul 1, 2:13 pm)
Re: A note on merging conflicts.., Johannes Schindelin, (Sat Jul 1, 11:23 am)
Re: A note on merging conflicts.., Linus Torvalds, (Fri Jun 30, 11:59 pm)
speck-geostationary