On Fri, Feb 17, 2012 at 11:29 PM, Jeff King <peff@xxxxxxxx> wrote: > On Fri, Feb 17, 2012 at 02:25:25PM -0800, Junio C Hamano wrote: > >> Jeff King <peff@xxxxxxxx> writes: >> >> > That being said, we do have an index extension to store the tree sha1 of >> > whole directories (i.e., we populate it when we write a whole tree or >> > subtree into the index from the object db, and it becomes invalidated >> > when a file becomes modified). This optimization is used by things like >> > "git commit" to avoid having to recreate the same sub-trees over and >> > over when creating tree objects from the index. But we could also use it >> > here to avoid having to even read the sub-tree objects from the object >> > db. >> >> Like b65982b (Optimize "diff-index --cached" using cache-tree, 2009-05-20) >> perhaps? > > That's what I get for speaking before running "git log". > > So yeah, we may be about as reasonably fast as we can go. Or maybe that > optimization isn't kicking in for some reason. I think going further > would require Piotr to do more profiling. Is the cache set? Not sure how to check it. t0090-cache-tree.sh uses test-dump-cache-tree and executes "read-tree HEAD" to establish the cache, but in my case read-tree does not make the cache dumpable (but it improves status performance). $ test-dump-cache-tree | wc -l 0 $ git read-tree HEAD $ test-dump-cache-tree | wc -l 0 $ echo 3 | sudo tee /proc/sys/vm/drop_caches && time git status -- . [...] real 0m1.085s git version 1.7.9.188.g12766 -- Piotr Krukowiecki -- 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