diff options
author | Derrick Stolee <dstolee@microsoft.com> | 2017-12-04 09:06:03 -0500 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2017-12-04 10:38:55 -0800 |
commit | 163ee5e635233f8614c29c11c9b8ee02902d65c4 (patch) | |
tree | 196a45db2152de2de42ed3b71a66d04dd40aa08b /git-gui/Makefile | |
parent | Sync with v2.15.1 (diff) | |
download | tgif-163ee5e635233f8614c29c11c9b8ee02902d65c4.tar.xz |
sha1_file: use strbuf_add() instead of strbuf_addf()
Replace use of strbuf_addf() with strbuf_add() when enumerating
loose objects in for_each_file_in_obj_subdir(). Since we already
check the length and hex-values of the string before consuming
the path, we can prevent extra computation by using the lower-
level method.
One consumer of for_each_file_in_obj_subdir() is the abbreviation
code. OID abbreviations use a cached list of loose objects (per
object subdirectory) to make repeated queries fast, but there is
significant cache load time when there are many loose objects.
Most repositories do not have many loose objects before repacking,
but in the GVFS case the repos can grow to have millions of loose
objects. Profiling 'git log' performance in GitForWindows on a
GVFS-enabled repo with ~2.5 million loose objects revealed 12% of
the CPU time was spent in strbuf_addf().
Add a new performance test to p4211-line-log.sh that is more
sensitive to this cache-loading. By limiting to 1000 commits, we
more closely resemble user wait time when reading history into a
pager.
For a copy of the Linux repo with two ~512 MB packfiles and ~572K
loose objects, running 'git log --oneline --parents --raw -1000'
had the following performance:
HEAD~1 HEAD
----------------------------------------
7.70(7.15+0.54) 7.44(7.09+0.29) -3.4%
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'git-gui/Makefile')
0 files changed, 0 insertions, 0 deletions