Re: auto gc again

Nicolas Pitre [off-list ref] writes:

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

quoted

Linus Torvalds [off-list ref] writes:

quoted

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

...

quoted

 - make the default for autopacklimit rather higher (pick number at 
   random: 50 instead of 20).

   Rationale: the reason for "git gc --auto" wasn't to keep things 
   perfectly packed, but to avoid the _really_ bad cases. The old default 
   of 20 may be fine if you want to always keep the repo very tight, but 
   that wasn't why "git gc --auto" was done, was it?

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?

Note that the current fetch.unpackLimit might play a role as well, 
especially if you fetch often (often meaning that you're more likely to 
have the received pack exploded into loose objects, or you're 
accumulating many small packs).

Ah, yes, native fetch will also result in a new pack, so even if you do
not do anything else, if you fetch once a day, you will accumulate 20
packs in that many days.

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

Nicolas Pitre [off-list ref] writes:

quoted

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

quoted

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