TortoiseHg 运行缓慢。

20

简单来说,TortoiseHg很慢。

我们团队最近从Subversion迁移到了Mercurial。(部分原因是为了利用Kiln进行代码审查)我们注意到,通过TortoiseHg与Mercurial交互非常缓慢。以下是一些统计数据:

  • 打开TortoiseHg工作台:8分钟13秒
  • 点击修订版本的响应时间:2.8秒
  • “刷新当前存储库”的时间:6.4秒
  • 检查传入更改所需的时间:12.8秒

所有这些都导致整个应用程序感觉非常缓慢。为了参考,以下是命令行工具的时间:

  • hg status:4.573秒
  • hg incoming:12.150秒

命令行工具的时间似乎与工作台的时间相吻合,但由于使用程序是同步的,所以工作台使延迟变得更加令人沮丧。例如,一个典型的任务是“获取我的同事刚刚推送的最新内容”。它看起来像这样(仅列出在计算机上等待的时间,取整):

  • 打开TortoiseHg:10分钟。
  • 通过在存储库注册表中双击来打开相应的存储库:5秒。
  • 提交需要提交的本地更改:
    • 单击“工作目录”:5秒。
    • 选择重要文件并输入提交消息。
    • 按提交:20秒。
  • 获取同事的更改:
    • 检查传入的变更集:10秒。
    • 审查它们。
    • 接受传入的变更集:40秒。
  • 暂存未准备好的更改:
    • 打开暂存对话框:2秒。
    • 暂存剩余文件:6分钟。
    • 刷新:5秒。
  • 合并:
    • 单击其他版本:3秒。
    • 与本地合并:
    • 等待“清理”验证:15秒。
    • 等待合并(假设没有冲突):10秒。
    • 提交:30秒。
  • 取消保留更改:
    • 打开保留对话框:2秒。
    • 取消保留:6分钟。
    • 刷新:5秒。

总计:24分32秒。

这其中有12分钟用于保留和取消保留。还有10分钟仅用于打开操作。这导致人们往往会提交一些他们不确定是否需要的东西,只是为了避免保留的成本。但即使你假设没有保留和打开的成本(也许你只是让它保持打开状态),仍需要精细的点击2分半钟才能得到最新的内容。

而且这还不包括像克隆等更重要的操作。所有的操作都很慢。

我已经:

  • 关闭了杀毒软件。
  • 禁用了索引功能。
  • 重新启动了计算机。
  • 尝试在3个不同版本的Windows上进行。
  • 在各种合理品质的硬件上尝试:Core 2 Duo @3.16 GHz,8Gb内存。
  • 在32位和64位操作系统上尝试。
  • 在断开网络的情况下尝试了这个操作。

这个仓库实际上包含两个仓库: 一个主要仓库和一个子仓库,其中包含我们所有的第三方二进制文件。主仓库的 .hg 文件夹大小为 676 MB。子仓库的 .hg 文件夹大小为 641 MB。主仓库中 default 的内容为 7.05 GB。子仓库中 default 的内容为 642 MB。主仓库中的平均文件大小为 563 KB。主仓库中最大的文件大小为 170 MB。主仓库中有 13,438 个文件。子仓库中的平均文件大小为 23KB。子仓库中最大的文件大小为 132 MB。子仓库中有 57087 个文件。

我启用了 big-push、caseguard、fetch、gestalt、kbfiles、kiln、kilnauth、kilnpath、mq、purge 和 transplant 扩展。

有没有任何想法从哪里开始找出如何加快速度?速度缓慢让我们发疯。


1
我想知道它是否正在尝试访问/在网络驱动器上超时?也许尝试在不在网络上的机器上运行它,即使只是为了测试工作台的启动时间。 - prunge
2
这绝对不是普通的TortoiseHg速度,它飞快地快。 - Laurens Holst
1
你启用了哪些扩展?仓库是在本地硬盘还是网络驱动器上被 Workbench 跟踪的? - Tim Henigan
好的,我已经添加了关于存储库大小和启用哪些扩展的答案。所有数据都不在网络驱动器上。所有本地克隆都在本地驱动器上。如果有影响,远程存储库是通过ssh访问的。(尽管似乎没有任何缓慢的事情与远程访问有关。)我尝试禁用网络,但性能似乎并未受到影响。 - alficles
我建议你在Mercurial开发者列表上提出这个问题。我认为你需要专业的帮助。http://mercurial.selenic.com/wiki/MailingLists#The_Mercurial-Devel_list - Tim Henigan
显示剩余4条评论
3个回答

28

好的,我回答自己的问题是因为我遵循了Tim的建议并找到了答案。

罪魁祸首是来自FogCreek的 kbfiles 。禁用它将状态时间从12秒降至0.7秒。同样,GUI打开得比我计时快。重新启用它会导致所有东西再次严重减慢。

并不是每件事都可以归咎于kbfiles,但其中最糟糕的确实可以。(具体来说,shelve仍然相当缓慢 - 受CPU限制。我们可以绕过这个问题。)


3
太好了!现在我回答自己的问题也不觉得傻了。 :) - alficles
您可能需要考虑告知FogCreek关于性能问题。 - cdeszaq
1
@alficles 我很好奇你如何解决储存的速度慢的问题。我发现储存非常缓慢(大量文件需要花费数分钟)。 - Kohanz
@Kohanz 大部分是通过不搁置来实现的。我使用多个分支和头,但这可能需要在其他地方进行讨论。 - alficles
hg shelve 命令比 THG 版本的 shelve 更快。 - StayOnTarget
显示剩余3条评论

2
这是一大堆文件... 其中一些非常大。没有这些大文件,它的表现如何?在我看来,二进制文件不是使用hg/git跟踪的最好方式。
将大仓库拆分成小仓库怎么样?它们真的需要分成两个巨大的仓库吗?
也许对硬盘进行碎片整理可以稍微改善某些时间。还要查看已创建的扩展名,以帮助专门处理大型二进制文件。请参见此处: https://www.mercurial-scm.org/wiki/HandlingLargeFiles

只有相当少量的大文件。我早期进行了检查,慢速似乎并不在于大文件的大小。(早期存在一些内存溢出问题,与一些超大文件有关,但这些问题现在已经不存在了。)大部分问题出现在主库中。90%的文件都是编译单个应用程序所必需的。如果我拆分主库,那么开发人员将只需要hg stat十个不同的库,而不是一个。更有可能的是,他们会忘记文件,从而破坏构建。 - alficles

1
在某些情况下,文档中提供的建议 可能有助于提高THG速度

5.4.8. 性能影响

在大型存储库中,某些Workbench功能可能会对性能产生影响。

查看 ‣ 选择日志列...

  • 启用 更改 列可能计算成本很高,导致刷新和滚动变慢

查看 ‣ 加载全部

  • 通常,当用户浏览历史记录时,会随着滚动读取一部分变更集。此菜单选项允许您从存储库中读取所有变更集,可能使历史记录的移动更加平滑

根据我的经验,这些绝对值得做!您至少应该尝试它们,并查看是否有明显的效果。


此外,如果您阅读了为什么mercurial的hg rebase如此缓慢? ,则有一个设置可以显著加快rebase的速度:

By default, rebase writes to the working copy, but you can configure it to run in-memory for better performance, and to allow it to run if the working copy is dirty. Just add following lines in your .hgrc file:

[rebase]

experimental.inmemory = True

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接