On 7/23/2018 1:03 PM, Duy Nguyen wrote:
On Mon, Jul 23, 2018 at 5:50 PM Ben Peart <peart...@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?
