Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15

Re: [PATCH 2/2] Implement a simple delta_base cache

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:43:00


On Sat, 17 Mar 2007, Junio C Hamano wrote:
This largely would depend on the project, but if a blob that is
cached is 20kB each, a 1024-entry cache would grow to 20MB.  We
may need to introduce early eviction of cached objects with
total cache size limit, configurable per repository.
One thing that I considered was to limit the delta-base cache to just tree 
entries. Those tend to be the really performance-sensitive ones - by the 
time you actually unpack blob entries, you're going to do something with 
that *single* entry anyway (like compare it to another blob), and the cost 
of unpacking the entry is likely to not be really all that noticeable.

That said, it was just simpler to do it unconditionally, and it obviously 
*works* fine regardless of the object type, so limiting it to trees is a 
bit sad. And since the intensive tree operations tend to be in a separate 
phase (ie the commit simplification phase) from the the blob operations 
(say, doing "git log -p <pathspec>"), I suspect that the cache locality 
would still remain good.

So I didn't do anything along the lines of "only cache for case Xyzzy".

But yes, especially if a project has big blobs, it might make sense to 
limit by full size of the cached entries some way.

			Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help