Jeff King <p...@peff.net> writes: > So while the value for that case _isn't_ as good as the > optimal one measured above (which was 2048 entries), given > the bouncing I'm hesitant to suggest that 2048 is any kind > of optimum (not even for linux.git, let alone as a general > rule). The generic hashmap has the appeal that it drops the > number of tweakable numbers by one, which means we can focus > on tuning other elements, like the LRU strategy or the > core.deltaBaseCacheLimit setting. > > And indeed, if we bump the cache limit to 1G (which is > probably silly for general use, but maybe something people > with big workstations would want to do), the linux.git log-S > time drops to 3m32s. That's something you really _can't_ do > easily with the static hash table, because the number of > entries needs to grow in proportion to the memory limit (so > 2048 is almost certainly not going to be the right value > there). > > This patch takes that direction, and drops the static hash > table entirely in favor of using the hashmap.h API.
Sounds very sensible. -- 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
