Thread (9 messages) flat view 9 messages, 3 authors, 2016-06-15

Re: Git-status / preload_index() performance

From: Karsten Blees <hidden>
Date: 2016-06-15 23:01:44

Am 25.06.2014 01:12, schrieb David Turner:
On Wed, 2014-06-25 at 00:52 +0200, Karsten Blees wrote:
quoted
Even more time is spent unpacking the HEAD tree, even with hot cache (repacking with depth 10 reduces this to ~250ms, on SSD its just 7ms). Perhaps caching the HEAD tree in an index extension could help here?
This is approximately what the cache-tree extension does.  However, it's
a bit broken.  I've been working on a fix, but slowly because my other
work has taken me longer than expected.  You can see the effect of the
cache-tree extension by doing git reset --hard HEAD; this temporarily
restores that extension.
Indeed:

01:32:35.965910 builtin/commit.c:1374   performance: 0.097505786 s: cmd_status:setup
...
01:32:36.047534 preload-index.c:129     performance: 0.081458337 s: read_index_preload
01:32:36.056204 read-cache.c:1226       performance: 0.008641527 s: refresh_index
01:32:36.059237 builtin/commit.c:1385   performance: 0.002997060 s: cmd_status:update_index
01:32:36.065163 wt-status.c:630         performance: 0.005732979 s: wt_status_collect_changes_worktree
01:32:36.072078 wt-status.c:638         performance: 0.006832976 s: wt_status_collect_changes_index
01:32:36.072150 wt-status.c:643         performance: 0.000000374 s: wt_status_collect_untracked
01:32:36.072211 trace.c:414             performance: 0.204069579 s: git command: 'git' 'status' '-s' '-uno'

Thanks
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help