On Wed, Feb 22, 2012 at 9:55 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes: > >> 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. > > Why do I have this funny feeling that we saw that comment in this thread > already? Simple. You wrote it and I missed it. On Sat, Feb 18, 2012 at 5:25 AM, Junio C Hamano <gitster@xxxxxxxxx> 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? This optimizes the case when a cached tree matches entirely.I wonder whether it's faster if we switch to tree-tree diff whenever we find valid cached trees. If cache-tree is fully valid, "git diff --cached foo" would be equivalent to "git diff HEAD foo". I tried "git diff --raw HEAD HEAD~100" (where HEAD was v3.1-rc1-272-g73e0881 on linux-2.6) and "git diff --cached --raw HEAD~100" with no cache-tree. The former is a little bit faster than the latter (177ms vs 275ms). On gentoo-x86, 70k worktree files, it's 4.33s vs 4.45s. But in tree-tree diff we pay high in cold cache case for loading trees from "HEAD". So no, probably not worth more code changes. Your optimization is good enough. -- 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