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

[Ben Peart <peartben@gmail.com>]

On 7/23/2018 1:03 PM, Duy Nguyen wrote:
> On Mon, Jul 23, 2018 at 5:50 PM Ben Peart <peartben@gmail.com> wrote:
>>> Anyway, on to the actual discussion:
>>>
>>>> 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?