Re: RFC: Flat directory for notes, or fan-out? Both!

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 10, 2009, 15:58 UTC
Message-ID: <7vprhqnv0c.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.00.0902101427490.10279@pacific.mpi-cbg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 17 quoted lines

>> OK. I think if you are seeing performance benefits from a 2-character
>> fanout, then we should standardize on that (do you have new performance
>> numbers somewhere?).
>
> The thing is: Shawn is correct when he says that a tree object to hold the 
> notes of all commits (which is not an unlikely scenario if you are 
> thinking about corporate processes) would be huge.
>
>> The notes implementation is now in master. If it's about to change in an 
>> incompatible way, how do you want to handle it? I'm wary of a quick 
>> patch to change the format this late in the release cycle. We could hold 
>> it back from 1.6.2. Alternatively, we could let it release with a "this 
>> is probably going to change" warning.
>> 
>> I think I favor holding it back, but I am not picky.
>
> Yes, I am also in favor of holding it back.

I could do a revert on 'master' if it is really needed, but I found that the above reasoning is a bit troublesome. The thing is, if a tree to hold the notes would be huge to be unmanageable, then it would still be huge to be unmanageable if you split it into 256 pieces.

I'd rather prefer to see us first try to find a way to optimze the tree parser. Maybe packv4 or Linus's binary search (which IIRC you declared would not work --- I recall I once thought about it myself but I do not recall what my conclusions were) play a role in it.