我正在尝试从以下几个存储库中提取git日志：
git log --pretty=format:%H\t%ae\t%an\t%at\t%s --numstat
对于较大的存储库（如rails / rails），生成日志需要35秒以上。
有没有办法改善这种表现？
答案 0 :(得分：3)
我的第一个想法是改进你的IO，但我使用SSD测试了rails存储库并得到了类似的结果：30秒。
--numstat正在减慢所有内容的速度，否则即使格式化，git-log也可以在1秒内完成。做一个差异是很昂贵的，所以如果你可以从你的过程中删除它将极大地加快速度。或许在事后这样做。
否则，如果您使用git-log自己的搜索工具过滤日志条目，这将减少需要执行差异的条目数。例如，git log --grep=foo --numstat只需一秒钟。They're in the docs under "Commit Limiting"。这可以大大减少git必须格式化的条目数。修订范围，日期过滤器，作者过滤器，日志消息grepping ......所有这些都可以在执行昂贵的操作时提高git-log在大型存储库上的性能。
答案 1 :(得分：3)
你是对的，在生成224＆000; 000行（15MiB）输出的56和000次提交中生成报告确实需要20到35秒。我实际上认为这是相当不错的表现，但你不是;好的。
因为您使用来自不变数据库的常量格式生成报告，所以您只需执行一次。之后，您可以使用git log的缓存结果并跳过耗时的生成。例如：
git log --pretty=format:%H\t%ae\t%an\t%at\t%s --numstat > log-pretty.txt
您可能想知道在整个报告中搜索感兴趣的数据需要多长时间。这是一个值得提出的问题：
$ tail -1 log-pretty.txt
30 0 railties/test/webrick_dispatcher_test.rb
$ time grep railties/test/webrick_dispatcher_test.rb log-pretty.txt
…
30 0 railties/test/webrick_dispatcher_test.rb
real 0m0.012s
…
不错，引入了一个＆＃34;缓存＆＃34;将所需时间从35秒减少到十几毫秒。这几乎快了3000倍。
答案 2 :(得分：3)
TLDR;作为mentioned in GitMerge 2019：
git config --global core.commitGraph true
git config --global gc.writeCommitGraph true
cd /path/to/repo
git commit-graph write
Git 2.18（2018年第二季度）将提高git log表现：
commit 902f5a2见René Scharfe (rscharfe)（2018年3月24日）
请commit 0aaf05b查看commit 3d475f4，Derrick Stolee (derrickstolee)（2018年3月22日）
请commit 626fd98见brian m. carlson (bk2204)（2018年3月22日）
（Junio C Hamano -- gitster --合并于commit 51f813c，2018年4月10日）
sha1_name：使用bsearch_pack()缩写计算对象ID的缩写长度时 packfile，当前实现的方法
find_abbrev_len_for_pack()二分搜索。
这是几种实施方式之一 此实现的一个问题是它忽略了pack-index中的扇出表。翻译此二进制搜索以使用现有的
bsearch_pack()方法 正确使用扇出表。由于使用了扇出表，缩写计算是 比以前快一点。
对于Linux repo的完全重新打包的副本，以下'git log'命令得到了改进：
* git log --oneline --parents --raw
Before: 59.2s
After: 56.9s
Rel %: -3.8%
* git log --oneline --parents
Before: 6.48s
After: 5.91s
Rel %: -8.9%
相同的Git 2.18添加了提交图：在一个单独的文件中预先计算和存储祖先遍历所需的信息，以优化图形行走。
请参阅commit 7547b95，commit 3d5df01，commit 049d51a，commit 177722b，commit 4f2542b，commit 1b70dfd，commit 2a2e32b（2018年4月10日） ，commit f237c8b，commit 08fd81c，commit 4ce58ee，commit ae30d7b，commit b84f767，commit cfe8321，commit f2af9f5（2018年4月2日）{ {3}}。
（由Derrick Stolee (derrickstolee)合并于Junio C Hamano -- gitster --，2018年5月8日）
集成
commit：将提交图与提交解析教Git检查提交图文件以提供a的内容 调用commit b10edb2时的struct commit 此实现满足struct commit的所有后置条件，包括加载父项，根树和提交日期。
如果
core.commitGraph为false，则不要检查图形文件。在测试脚本
parse_commit_gently()中，添加output-matching条件 只读图形操作。通过从图中加载提交而不是解析提交缓冲区，我们 节省大量时间进行长时间的提交。
以下是Linux存储库副本的一些性能结果，其中'master'具有678,653个可达提交，并且落后于'
origin/master'59,929次提交。
| Command | Before | After | Rel % |
|----------------------------------|--------|--------|-------|
| log --oneline --topo-order -1000 | 8.31s | 0.94s | -88% |
| branch -vv | 1.02s | 0.14s | -86% |
| rev-list --all | 5.89s | 1.07s | -81% |
| rev-list --all --objects | 66.15s | 58.45s | -11% |
要了解有关提交图的详情，请参阅“t5318-commit-graph.sh”。
同样的Git 2.18（2018年第二季度）添加了延迟加载树。
已经教导代码使用存储的重复信息 在commit-graph文件中学习提交的树对象名称 避免在有意义时打开和解析提交对象 这样做。
How does 'git log --graph' work?见commit 279ffad（2018年4月30日）
SZEDER Gábor (szeder)见commit 7b8a21d，commit 2e27bd7，commit 5bb03de，commit 891435d（2018年4月6日）。{
（由Derrick Stolee (derrickstolee)合并于Junio C Hamano -- gitster --，2018年5月23日）
commit-graph：提交的延迟加载树提交图文件提供对提交数据的快速访问，包括 图中每次提交的根树的OID。表演时 深度提交图形遍历，我们可能不需要加载大多数树 对于这些提交。
延迟加载树对象以从图中加载提交 直到通过
get_commit_tree()提出要求 不要为不在图中的提交延迟加载树，因为这需要重复解析，并且当不需要树时相对性能提升很小。在Linux存储库中，针对以下内容运行了性能测试 命令：
git log --graph --oneline -1000 Before: 0.92s After: 0.66s Rel %: -28.3%
Git 2.21（2019年第一季度）增加了松散缓存。
commit c89b6e1（201年1月7日）和commit 8be88db，commit 4cea1ce，commit d4e19e5（2019年1月6日）commit 0000d65。
（由René Scharfe (rscharfe)合并于Junio C Hamano -- gitster --，2019年1月18日）
object-store：每个子目录使用一个oid_array进行松散缓存松散对象缓存根据需要一次填充一个子目录 它存储在
oid_array中，必须在每次添加操作后使用。{ 因此，在查询各种对象时，部分填充的数组最多需要使用255次，这比排序一次要长100倍。每个子目录使用一个
oid_array这确保了条目必须只进行一次排序。它还避免了每个缓存查找的八个二进制搜索步骤作为一个小额外奖励。缓存用于对日志占位符
%h，%t和%p进行冲突检查，我们可以看到更改将它们加速到存储库中。每个子目录100个对象：$ git count-objects 26733 objects, 68808 kilobytes Test HEAD^ HEAD -------------------------------------------------------------------- 4205.1: log with %H 0.51(0.47+0.04) 0.51(0.49+0.02) +0.0% 4205.2: log with %h 0.84(0.82+0.02) 0.60(0.57+0.03) -28.6% 4205.3: log with %T 0.53(0.49+0.04) 0.52(0.48+0.03) -1.9% 4205.4: log with %t 0.84(0.80+0.04) 0.60(0.59+0.01) -28.6% 4205.5: log with %P 0.52(0.48+0.03) 0.51(0.50+0.01) -1.9% 4205.6: log with %p 0.85(0.78+0.06) 0.61(0.56+0.05) -28.2% 4205.7: log with %h-%h-%h 0.96(0.92+0.03) 0.69(0.64+0.04) -28.1%
答案 3 :(得分：0)
还有另一条提高git log性能的途径，它建立在提到的in the previous answer提交图之上。
Git 2.27（2020年第2季度）引入了对提交图的扩展，以使其高效地检查使用 Bloom filters在每次提交时修改的路径。
请参见commit caf388c前的commit e369698（2020年4月9日）和Derrick Stolee (derrickstolee)（2020年3月30日）。
参见commit d5b873c，commit a759bfa，commit 42e50e7，commit a56b946，commit d38e07b，commit 1217c03，commit 76ffbca（2020年4月6日）和{ {3}}的{3}}，commit 3d11275，commit f97b932，commit ed591fe，commit f1294ea，commit f52207a（2020年3月30日）。
请参见commit 3be7efc的Garima Singh (singhgarima)（2020年3月30日）。
（由commit d21ee7d在Jeff King (peff)中合并，2020年5月1日）