On Wed, Feb 22, 2012 at 2:16 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Because prime_cache_tree() by itself is a fairly expensive operation that > reads all the trees recursively, its benefits need to be evaluated. It > should to happen only in an operation that is already heavy-weight, is > likely to have read all the trees and have many of them in-core cache, and > also relatively rarely happens compared to "git add" so that the cost can > be amortised over time, such as "reset --(hard|mixed)". > > Switching branches is likely to fall into that category, but that is just > my gut feeling. I would feel better at night if somebody did a benchmark > ;-) In this particular case, "git diff --cached" is run internally, so I say all trees are read once and hopefully most of them still in OS cache. Will run some benchmark, maybe with the coming perf test suite. > One thing we do not currently do anywhere that _might_ be of merit is to > make a call to cache_tree_update() instead of prime_cache_tree() when we > already know that only a very small subpart of the cache-tree is invalid > and it is cheaper to repair it by rehashing only a small portion of the > index than to re-prime the entire cache tree with prime_cache_tree(). That makes me think if "diff --cached" can take advantage of cache-tree to avoid walking down valid cached trees and do tree-tree diff in those cases instead. Not sure if it gains us anything but code complexity. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html