缓慢的 Git 操作答案

【问题标题】：Slow Git operations缓慢的 Git 操作
【发布时间】：2012-03-12 15:25:25
【问题描述】：

我有一个放在 Git 下的测试存储库。大多数文件都很小，但数量非常多，简单的 Git 操作（如 add 和 status）需要数十分钟才能完成。我有哪些选择可以将这些置于修订控制之下并获得合理的性能？我应该尝试使用子模块还是应该避开 DVCS？

【问题讨论】：

你正在处理什么样的文件系统？
众所周知，Git 能够快速处理大型项目。您使用的是慢速文件系统吗？
安装在 NFS 上，虽然头部相当高端。
根据 NFS 信息更新了我的答案。我认为这是这里的关键信息。如果可能，我会考虑对其进行本地克隆，但如果没有，请查看线程和配置选项。
我在本地 SSD 文件系统上的 git reset 操作也很慢。仓库相当大——Cocoapods 本地规范。

标签： git

【解决方案1】：

像 add 和 status 这样的 Git 操作需要 stating 文件系统中的每个文件（以检测更改）。要么您拥有大量文件（例如，数万或数十万个文件），要么您的文件系统具有相当慢的 stat 操作。

在任何情况下，如果您需要在一个速度极慢的系统上工作，您可以使用索引中的“假设未更改”位，它告诉 Git 不要打扰 stating 文件。如果您确实打开了此功能，则需要手动指示 git 获取单个文件中的更改，例如通过将它们直接传递给git add，否则 Git 甚至都不知道有什么变化。您可以通过设置git config core.ignoreStat true 来打开它，然后运行git reset --hard HEAD 之类的东西。

【讨论】：

宾果游戏！我没有计算它们，因为我害怕，但我不会惊讶地发现它有数十万甚至数百万个文件，几乎都是人类生成的。我尝试设置该标志，它对某些操作有所帮助，但仍然太慢。也许我应该创建大量的小型存储库。

【解决方案2】：

我想知道这里的“非常大”的数字是什么。通常 git 发现麻烦的不是小文件的数量，而是大的二进制文件。但是，我可以想象，如果数量足够大，您可能希望将它们拆分为多个存储库 - 通过子模块或其他方式。如果它们需要驻留在一个存储库中，您可能会发现 Subversion 的性能更高。

编辑：好的，所以您添加了使用 NFS 挂载的注释，这听起来像是这里可能的瓶颈。请在this thread 中查看解决方案。特别是 core.preloadindex 可能在这里很有趣。

来自the documentation：

core.preloadindex

为 git diff 等操作启用并行索引预加载

这可以加快 git diff 和 git status 等操作，尤其是在像 NFS 这样具有弱缓存语义的文件系统上，因此相对较高的 IO 延迟。将此设置为 true，git 将执行与文件系统数据并行进行索引比较，允许重叠的 IO。

EDIT2：在 cmets 上提到了 600 万个文件。我可以理解这会成为一个瓶颈——这确实是一个非常大的数量。

【讨论】：

我不知何故怀疑 SVN 比 git 性能更好——即使是这样，git 也好得多（根据 Linus Torvalds 的说法，你在不使用 Git 时是丑陋和愚蠢的：p）
好吧，你不必只相信我的话——即使是 Linus agrees，对于某些用例来说就是这种情况。 Git 作为一个整体在 repo 上运行，因此在某些情况下它不是最佳选择。
二进制文件很少。文件的数量远远大于您在任何单个开源项目中找到的数量。
我们的工作是大约 50k 个文件，这不是问题。但是，如果您有数十万甚至数百万之类的东西，我可以看到这将成为瓶颈。我很想知道 svn 或 perforce 将如何处理任何数字......如果你测试它们并且你在某个地方有数字，请也让我们知道:)
大约有 600 万个文件。一个 git status 操作大约需要 2 个小时才能完成，core.preloadindex 设置为 true。