Re: git gc --aggressive led to about 40 times slower "git log --raw"
- From
David Kastrup <dak@gnu.org>
- Date
- Feb 20, 2014, 18:07 UTC
- Message-ID
- <87ppmhr72d.fsf@fencepost.gnu.org>
- In-Reply-To
- <87y515r9wb.fsf@fencepost.gnu.org>
David Kastrup <dak@gnu.org> writes:
Show 20 quoted lines
> David Kastrup <dak@gnu.org> writes: > >> Duy Nguyen <pclouds@gmail.com> writes: >> >> Something's _really_ fishy about that cache behavior. Note that the >> _system_ time goes up considerably, not just user time. Since the >> packs are zlib-packed, it's reasonable that more I/O time is also >> associated with more user time and it is well possible that the user >> time increase is entirely explainable by the larger amount of >> compressed data to access. >> >> But this stinks. > > And an obvious contender for the stinking is that the "LRU" scheme used > here is _strictly_ freeing memory based on which cache entry has been > _created_ the longest time ago, not which cache entry has been > _accessed_ the longest time ago. Which means a pure round-robin > strategy for freeing memory rather than LRU. > > Let's see what happens when changing this.
Not much. With any cache size, using a "true" LRU scheme does not buy more than 2%. On the other hand, increasing core.deltaBaseCacheLimit from its default of 16m to 128m in the config file results in the following difference (with default #define MAX_DELTA_CACHE (256)):
dak@lola:/usr/local/tmp/emacs$ time ../git/git blame src/xdisp.c >/dev/null
real 1m17.446s user 0m30.696s sys 0m46.332s dak@lola:/usr/local/tmp/emacs$ time ../git/git blame src/xdisp.c >/dev/null
real 0m27.519s user 0m20.248s sys 0m7.156s
So it would seem that the default available cache slots are not utilized anyway when operating on this file (about 1MB in size) with the default of core.deltaBaseCacheLimit.
It is still irritating that the performance drops quite a bit with a considerably larger number of cache slots.
-- David Kastrup