【问题标题】:hg status is slow the first timehg状态第一次很慢
【发布时间】:2010-08-24 15:58:48
【问题描述】:

有谁知道为什么hg status 第一次在 Windows 客户端上从命令行调用它时很慢(3-10 秒)(我假设它在那之后被缓存了)。

hg status 是一个本地操作,它不应该花费那么长时间,尤其是对于空仓库。

在具有多项更改的活动存储库和没有文件的全新存储库中都是这种情况。因此,repo 的大小似乎并不是影响性能的因素。 谢谢!

【问题讨论】:

  • 是在 Windows 上吗?看看你对命令行有没有同样的体验?
  • 是的。运行 windows & 我正在使用命令行。
  • 也许使用 hg --profile 会提供一些有用的提示。
  • “第一次”能说清楚一点吗?安装hg后第一次?重启后第一次?第一次在每个新的 cmd 窗口中?第一次在任何一个 repo 中?
  • 两个“-”,不是一个。喜欢hg --profile status

标签: mercurial tortoisehg


【解决方案1】:

当您运行hg status 命令时,Mercurial 必须扫描您存储库中的几乎每个目录和文件,以便它可以显示文件状态。 Hg 必须为每个托管文件执行至少一次昂贵的系统调用,以确定自上次 Mercurial 检查以来它是否已更改,这是无法避免的。

我相信后续对hg st 的调用速度更快的原因是操作系统保留了有关所有最近访问的文件的缓存信息——如果文件没有被修改,则避免磁盘访问——。有时文件本身甚至可能保留由操作系统映射的内存或完全缓存在 HDD 缓冲区上。

编辑:另外,如果您有一段时间没有调用 hg,操作系统将需要从磁盘读取 hg 可执行文件及其依赖项,因为它们可能尚未缓存在 RAM 上。

【讨论】:

  • 谢谢!这就回答了!然而,这意味着一个空的(或非常小的)回购应该非常快,这在我见过的所有情况下都不是真的。
  • 是的,因为即使 repo 很小(或为空!),操作系统仍然需要加载和缓存 Hg 及其所有依赖项(例如 Python 运行时)
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-04-27
  • 2017-07-23
  • 2017-05-23
  • 1970-01-01
相关资源
最近更新 更多