Re: [PATCH v1 0/3] [RFC] Speeding up checkout (and merge, rebase, etc)

On 7/23/2018 1:03 PM, Duy Nguyen wrote:

On Mon, Jul 23, 2018 at 5:50 PM Ben Peart [off-list ref] wrote:

quoted

quoted

Anyway, on to the actual discussion:

quoted

Here is a checkout command with tracing turned on to demonstrate where the
time is spent.  Note, this is somewhat of a �best case� as I�m simply
checking out the current commit:

benpeart@gvfs-perf MINGW64 /f/os/src (official/rs_es_debug_dev)
$ /usr/src/git/git.exe checkout
12:31:50.419016 read-cache.c:2006       performance: 1.180966800 s: read cache .git/index
12:31:51.184636 name-hash.c:605         performance: 0.664575200 s: initialize name hash
12:31:51.200280 preload-index.c:111     performance: 0.019811600 s: preload index
12:31:51.294012 read-cache.c:1543       performance: 0.094515600 s: refresh index
12:32:29.731344 unpack-trees.c:1358     performance: 33.889840200 s: traverse_trees
12:32:37.512555 read-cache.c:2541       performance: 1.564438300 s: write index, changed mask = 28
12:32:44.918730 unpack-trees.c:1358     performance: 7.243155600 s: traverse_trees
12:32:44.965611 diff-lib.c:527          performance: 7.374729200 s: diff-index
Waiting for GVFS to parse index and update placeholder files...Succeeded
12:32:46.824986 trace.c:420             performance: 57.715656000 s: git command: 'C:\git-sdk-64\usr\src\git\git.exe' checkout

What's the current state of the index before this checkout?

This was after running "git checkout" multiple times so there was really
nothing for git to do.

Hmm.. this means cache-tree is fully valid, unless you have changes in
index. We're quite aggressive in repairing cache-tree since aecf567cbf
(cache-tree: create/update cache-tree on checkout - 2014-07-05). If we
have very good cache-tree records and still spend 33s on
traverse_trees, maybe there's something else.

I'm not at all familiar with the cache-tree and couldn't find any documentation on it other than index-format.txt which says "it helps speed up tree object generation for a new commit."  In this particular case, no new commit is being created so I don't know that the cache-tree would help.

After a quick look at the code, the only place I can find that tries to use cache_tree_matches_traversal() is in unpack_callback() and that only happens if n == 1 and in the "git checkout" case, n == 2. Am I missing something?