Re: [PATCH 0/2] A new merge algorithm, take 3

From: Junio C Hamano <junkio@cox.net>
Date: Sep 8, 2005, 16:51 UTC
Message-ID: <7v7jdrwlih.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <4320536D.2010706@citi.umich.edu>

Chuck Lever <cel@citi.umich.edu> writes:

Show 6 quoted lines

> Junio C Hamano wrote:
>> Chuck Lever <cel@citi.umich.edu> writes:
>>
> once the list implementation is working well, i plan to go back and 
> replace it with something more sophisticated which can perform 
> insertion, deletion, and searching efficiently.

Well, what I wanted to see was if we can get away without introducing more sophisticated data structures, which would add complexity.

Show 9 quoted lines

>> I haven't timed it like you did, but my gut feeling is that the
>> most wastage during the merge is coming from having to move
>> entries because we "insert into" or "remove from" the same
>> active-cache array.
>
> the merge actually replaces entries in place, so it is already fairly 
> efficient.  the wastage in the merge case arises from the many list 
> insertions done by read_cache, all of which involve moving some of the 
> active cache array.

Yes, the reading of three trees upfront is probably the culprit in your case, and I think that is something Daniel's read-tree rewrite can help. I still see some remove_cache_entry_at() there because it works on the active_cache in place, but the structure of the new code should be much easier to make the kind of modification we are talking about.

Show 7 quoted lines

>> I think what Daniel
>> did to read-tree recently, still in the proposed updates branch,
>> would make this kind of change far easier to implement.
>
> as i'm new to git development, i wasn't aware of the proposed branch.  i 
> will see if i can take a look (or send me a pointer to the list archives 
> if he has posted them here).

If you already have a local copy of git.git repository you work in:

	git fetch http://kernel.org/pub/scm/git/git.git +pu:refs/heads/ko-pu
        git checkout -f ko-pu

Otherwise

	git clone http://kernel.org/pub/scm/git/git.git peek
        cd peek
        git checkout -f pu

The interesting change from the mainline is in read-tree.c

You can browse http://kernel.org/git/ and see commitdiffs in the "pu" branch if you are not interested in slurping the whole proposed updates branch.