Re: auto gc again

From: Nicolas Pitre <nico@cam.org>
Date: Mar 20, 2008, 03:13 UTC
Message-ID: <alpine.LFD.1.00.0803192228260.2947@xanadu.home>
In-Reply-To: <7vd4pq1el3.fsf@gitster.siamese.dyndns.org>

On Wed, 19 Mar 2008, Junio C Hamano wrote:

Show 13 quoted lines

> Nicolas Pitre <nico@cam.org> writes:
> 
> >On Wed, 19 Mar 2008, Junio C Hamano wrote:
> >
> >> I do not think "very tight" was the reason, but on the other hand, my
> >> personal feeling is that 20 was already 10 too many pack idx files we have
> >> to walk linearly while looking for objects at runtime.
> >
> > Since commit f7c22cc68ccb this is no longer such an issue.
> 
> Notice that I did not say "19 too many".  I know f7c22cc (always start
> looking up objects in the last used pack first, 2007-05-30) was meant to
> alleviate the situation, but isn't "no longer" a gross exaggeration?

Not at all. Please have a second look at the performance numbers in that commit log, and take into accound the most important metric that I unfortunately failed to mention there (although I subsequently posted it to the list: http://marc.info/?l=git&m=118058197921642&w=2), wich is the time to perform the same operation with a single pack.

So you have 17.1 seconds for a single pack vs 18.4 seconds for 66 packs.

Compare that to 24.9s without that patch.

And I still have some further optimizations to implement eventually (http://marc.info/?l=git&m=118062793413099&w=2), but which would probably make a significant difference only in the hundreds-of-packs case anyway.

So I really think that the default gc.autopacklimit could be raised.

Nicolas