David Kastrup <d...@gnu.org> writes: > David Kastrup <d...@gnu.org> writes: > >> Duy Nguyen <pclo...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
