Re: auto gc again

Nicolas Pitre [off-list ref] writes:

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.

Very interesting --- why should it affect a single pack case at all?

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.

Thanks, let's raise it to 50 then.

But I am still puzzled...

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

Nicolas Pitre [off-list ref] writes:

quoted

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.

Very interesting --- why should it affect a single pack case at all?

It is not:

Single pack = 17.1s
66 packs with commit f7c22cc6 = 18.4s
66 packs without commit f7c22cc6 = 24.9s

The point is that having many packs doesn't impose a significant 
overhead anymore when comparing to the single pack case.

Thanks, let's raise it to 50 then.

Having only to set gc.auto=0 to disable it entirely is also a good 
thing.

But I am still puzzled...

Please tell me why if this is still the case.


Nicolas