Re: git status: small difference between stating whole repository and small subdirectory

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Feb 22, 2012, 02:12 UTC
Message-ID: <CACsJy8C3Myqs4=GvURWqCTxGp0R1RWotdiHGnnvBSaxyTteujw@mail.gmail.com>
In-Reply-To: <7v8vjwgfoq.fsf@alter.siamese.dyndns.org>

On Wed, Feb 22, 2012 at 2:16 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

> 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.

Show 5 quoted lines

> 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