git - 这个 git log 命令运行的时间越长，我使用它的次数越多，如何让它运行得更快？

Question

我碰巧在使用 git svn 桥，我不确定这是否相关。在我的“.gitconfig”中，我有一个 git lg 的别名，定义如下:

[alias]
        lg = log --max-count=100 --branches --color --graph --pretty=format:'%Cred%h%Creset - %C(bold blue)<%an>%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)' --abbrev-commit

当我第一次克隆这个存储库时，运行 git lg 几乎是瞬时的，但随着时间的推移，这个命令似乎变得越来越慢。现在 git lg 至少需要 30 秒。是什么导致它变慢，我怎样才能让它运行得更快？

Answer 1

检查您是否在后台禁用了 git gc ( as in here )，例如 git config gc.auto 设置为 0 或 git config gc.autodetach 为 false，或者 git config gc.pruneExpire 设置为 never。
然后你就不需要显式地使用 git gc。

更一般地说，如果 git log 再次变慢，您可以使用最新版本的 Git(2.23，2019 年 8 月)调用 perf tracing :

git -c trace2.perfTarget=~/perf.log log

然后您可以看到哪些内容仍然需要时间。

---

7 年后的更新，使用 Git 2.31(2021 年第一季度)，一些漂亮的格式说明符不需要提交对象中的数据(例如“%H”)，但我们过于渴望加载和解析它，这变得更加懒惰。

这有助于使一些 git log --pretty 更快。​​

参见 commit 018b9de (2021 年 1 月 28 日)作者:Jeff King (peff) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit 938ecaa ，2021 年 2 月 10 日)}

pretty: lazy-load commit data when expanding user-format

^{Reported-by: Michael Haggerty
Signed-off-by: Jeff King}

When we expand a user-format, we try to avoid work that isn't necessary for the output.
For instance, we don't bother parsing the commit header until we know we need the author, subject, etc.

But we do always load the commit object's contents from disk, even if the format doesn't require it (e.g., just "%H").
Traditionally this didn't matter much, because we'd have loaded it as part of the traversal anyway, and we'd typically have those bytes attached to the commit struct (or these days, cached in a commit-slab).

But when we have a commit-graph, we might easily get to the point of pretty-printing a commit without ever having looked at the actual object contents.
We should push off that load (and reencoding) until we're certain that it's needed.

I think the results of p4205 show the advantage pretty clearly (we serve parent and tree oids out of the commit struct itself, so they benefit as well):

# using git.git as the test repo
Test                          HEAD^             HEAD
----------------------------------------------------------------------
4205.1: log with %H           0.40(0.39+0.01)   0.03(0.02+0.01) -92.5%
4205.2: log with %h           0.45(0.44+0.01)   0.09(0.09+0.00) -80.0%
4205.3: log with %T           0.40(0.39+0.00)   0.04(0.04+0.00) -90.0%
4205.4: log with %t           0.46(0.46+0.00)   0.09(0.08+0.01) -80.4%
4205.5: log with %P           0.39(0.39+0.00)   0.03(0.03+0.00) -92.3%
4205.6: log with %p           0.46(0.46+0.00)   0.10(0.09+0.00) -78.3%
4205.7: log with %h-%h-%h     0.52(0.51+0.01)   0.15(0.14+0.00) -71.2%
4205.8: log with %an-%ae-%s   0.42(0.41+0.00)   0.42(0.41+0.01) +0.0%

# using linux.git as the test repo
Test                          HEAD^             HEAD
----------------------------------------------------------------------
4205.1: log with %H           7.12(6.97+0.14)   0.76(0.65+0.11) -89.3%
4205.2: log with %h           7.35(7.19+0.16)   1.30(1.19+0.11) -82.3%
4205.3: log with %T           7.58(7.42+0.15)   1.02(0.94+0.08) -86.5%
4205.4: log with %t           8.05(7.89+0.15)   1.55(1.41+0.13) -80.7%
4205.5: log with %P           7.12(7.01+0.10)   0.76(0.69+0.07) -89.3%
4205.6: log with %p           7.38(7.27+0.10)   1.32(1.20+0.12) -82.1%
4205.7: log with %h-%h-%h     7.81(7.67+0.13)   1.79(1.67+0.12) -77.1%
4205.8: log with %an-%ae-%s   7.90(7.74+0.15)   7.81(7.66+0.15) -1.1%

I added the final test to show where we don't improve (the 1% there is just lucky noise), but also as a regression test to make sure we're not doing anything stupid like loading the commit multiple times when there are several placeholders that need it.

---

另一种方法是使用 %d，如“How do I show tags in a custom git log format?”中所述。

Git 2.33(2021 年第 3 季度)速度更快，它优化了“git log”^(man)，以应对我们浪费周期来加载可能不需要的 ref 修饰数据的情况。

参见 commit d1ed8d6 (2021 年 7 月 14 日)，以及 commit 6afb265 , commit 88473c8 , commit 7463064 , commit 542d6ab , commit b2086b5 , commit 3c7e2e8 (2021 年 6 月 22 日)作者:Jeff King (peff) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit c9d6d8a，2021 年 7 月 28 日)}

load_ref_decorations(): avoid parsing non-tag objects

^{Signed-off-by: Jeff King}

When we load the ref decorations, we parse the object pointed to by each ref in order to get a "struct object".
This is unnecessarily expensive; we really only need the object struct, and don't even look at the parsed contents.
The exception is tags, which we do need to peel.

We can improve this by looking up the object type first (which is much cheaper), and skipping the parse entirely for non-tags.
This increases the work slightly for annotated tags (which now do a type lookup and a parse), but decreases it a lot for other types.

On balance, this seems to be a good tradeoff.

• In my git.git clone, with ~2k refs, most of which are branches, the time to run "git log -1 --decorate"^(man) drops from 34ms to 11ms.
• Even on my linux.git clone^(man), which contains mostly tags and only a handful of branches, the time drops from 30ms to 19ms.
• And on a more extreme real-world case with ~220k refs, mostly non-tags, the time drops from 2.6s to 650ms.

That command is a lop-sided example, of course, because it does as little non-loading work as possible.
But it does show the absolute time improvement.
Even in something like a full "git log --decorate"^(man) on that extreme repo, we'd still be saving 2s of CPU time.