Re: What's cooking in git.git (topics)

From: Junio C Hamano <junkio@cox.net>
Date: Mar 14, 2007, 11:27 UTC
Message-ID: <7vbqiwawva.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <8aa486160703131614i1b67e6c3vf7ccf395d63573b4@mail.gmail.com>

"Santi Béjar" <sbejar@gmail.com> writes:

Show 16 quoted lines

>> I tried the "NULL fetch between 1000-refs repositories" test,
>> which prompted the git-fetch--tool work that was done on
>> jc/fetch topic in 'next', with the following versions:
>>
>>  (1) 1.5.0 (without any git-fetch--tool optimization)
>>  (2) master (ditto)
>>  (3) master with jc/fetch (but not sb/fetch topic)
>>  (4) next ((3) plus sb/fetch and others)
>>
>> The test scripts are at the end of this message.  Both (1) and
>> (2) take 3 minutes 7 seconds wallclock time.  (3) improves it
>> down to 15 seconds.  (4) makes the operation spend 24 seconds
>> (the times are all on my primary machine x86-64 with 1GB, hot
>> cache and average of three runs each).
>
> I think it is not fair,...

That's a very unexpected response. I personally do not think the separation of FETCH_FETCHED made improvements to the code, but the above numbers do not have anything to do with such perhaps subjective ascetic judgement.

The comparison showed that the "Split" patch is a step backward from the existing optimization hack that was specifically made to solve an issue raised on the list, and you may not like the numbers, but if you call that is "not fair", I do not know what could be considered fair.

Yes, life is unfair, but I do not think that word applies to this particular case.