Re: [PATCH v1 0/3] [RFC] Speeding up checkout (and merge, rebase, etc)
- From
Ben Peart <peartben@gmail.com>
- Date
- Jul 23, 2018, 20:51 UTC
- Message-ID
- <6ff6fbdc-d9cf-019f-317c-7fdba31105c6@gmail.com>
- In-Reply-To
- <CACsJy8D-3sSnoyQZKxeLK-2RmpJSGkziAp5Gf4QpUnxwnhchSQ@mail.gmail.com>
On 7/23/2018 1:03 PM, Duy Nguyen wrote:
Show 31 quoted lines
> 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?