Re: [PATCH] Bump core.deltaBaseCacheLimit to 96m

From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: May 5, 2014, 11:03 UTC
Message-ID: <vpqwqe0a3ne.fsf@anie.imag.fr>
In-Reply-To: <CACsJy8BG8fRPk74R_-YABCGMn-YwbDcLHtjUNX7KE66jX1mR4A@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 26 quoted lines

> On Mon, May 5, 2014 at 12:13 AM, David Kastrup <dak@gnu.org> wrote:
>> The default of 16m causes serious thrashing for large delta chains
>> combined with large files.
>>
>> Here are some benchmarks (pu variant of git blame):
>>
>> time git blame -C src/xdisp.c >/dev/null
>
> ...
>
>> diff --git a/Documentation/config.txt b/Documentation/config.txt
>> index 1932e9b..21a3c86 100644
>> --- a/Documentation/config.txt
>> +++ b/Documentation/config.txt
>> @@ -489,7 +489,7 @@ core.deltaBaseCacheLimit::
>>         to avoid unpacking and decompressing frequently used base
>>         objects multiple times.
>>  +
>> -Default is 16 MiB on all platforms.  This should be reasonable
>> +Default is 96 MiB on all platforms.  This should be reasonable
>>  for all users/operating systems, except on the largest projects.
>>  You probably do not need to adjust this value.
>
> So emacs.git falls exactly into the "except on the largest projects"
> part. Would it make more sense to advise git devs to set this per repo
> instead?

What's the impact of changing the default for small projects?

My guess is that changing from 16 to 96Mb is just following Moore's law. Machines average RAM has increased a lot since the time 16Mb has been chosen, and few people would actually notice the difference in RAM usage nowadays.

If increasing the default does not harm small projects and benefits to big projects, then we should obviously go this way.

(perhaps adding advices for people using Git on machines with low RAM)

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/