Re: Debugging git-commit slowness on a large repo

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: Debugging git-commit slowness on a large repo

From: Thomas Rast <hidden>
Date: 2016-06-15 22:52:40

Joshua Redstone [off-list ref] writes:
As a bonus, I've also profiled git-add on the 1-million file repo, and it
looks like, as you might expect, the time is dominated by reading and
writing the index.  The time for git-add is a couple of seconds.
Note that the time to write the index itself is also rather small, but
the time needed to sha1 the index when loading and then again when
saving it really hurts.

(I noticed this while working on the commit-tree topic.)

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Debugging git-commit slowness on a large repo

From: Joshua Redstone <hidden>
Date: 2016-06-15 22:52:40

I looked again at my poor-mans-profiling output of git-add.  The Sha1
stuff under ce_write_entry->ce_write_flush  takes a bunch of time.
commit_lock_file->rename takes about the same as well.

Btw, the perf numbers for commit and add are with a warm file cache.  I
expect the benefit of skipping all the stat() calls will increase for cold
cache.

Josh

On 12/20/11 1:23 AM, "Thomas Rast" [off-list ref] wrote:
Joshua Redstone [off-list ref] writes:
quoted
As a bonus, I've also profiled git-add on the 1-million file repo, and
it
looks like, as you might expect, the time is dominated by reading and
writing the index.  The time for git-add is a couple of seconds.
Note that the time to write the index itself is also rather small, but
the time needed to sha1 the index when loading and then again when
saving it really hurts.

(I noticed this while working on the commit-tree topic.)

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help