9

问题:

我发现 EGit 很棒并且经常使用它,但它可能非常慢。当需要几分钟才能完成 C 版本的 git (Cgit) 在不到几秒钟的时间内完成的操作时,可能会令人沮丧。

所有操作都比 Cgit 慢得多。例如,与几乎即时相比,切换分支将花费 10 秒。与不到几秒钟相比,rebase 可能需要几分钟。

一些细节:

历史记录大小:10114 次提交,报告如下:git rev-list HEAD --count

当前工作目录大小:63.7 MB

当前 .git 大小:77.4 MB

最大文件大小:4.0 MB

操作系统:Linux - CentOS 5.5

文件系统:ext3

JVM:Oracle - Java(TM) SE 运行时环境(内部版本 1.7.0_21-b11)

EGit 和 JGit 版本:3.0.0.201306101825-r

我之前运行的是 2.3,但升级后没有注意到性能有任何变化。

合适的窗口缓存设置是否有帮助:

我在 JGit 的 bugzilla 中找到了以下引用:

...EGit 必须公开 UI 以允许用户在处理更大的存储库时对其进行配置。

这听起来很适合我的情况。所以我在eclipse中环顾四周,Window -> Preferences -> Team -> Git发现了这些Git Window Cache设置:

EGit 窗口缓存设置

但是我该如何使用它们呢?

不同的控件实际上做了什么?有没有人成功地通过使用 EGit 来提高响应速度?

4

3 回答 3

4

建议

正如Matthias Sohn 所建议的,窗口缓存限制似乎是这些参数中最重要的。

对我来说,将它从“10 m”增加到“500 m”对 egit 的响应速度产生了巨大的影响。

每个参数的详细信息

从WindowCacheConfig.java的源代码†</sup> :

窗户尺寸

packedGitWindowSize:映射或从包文件中读取的单个窗口的大小(以字节为单位)

默认值:8k

窗口缓存限制

packedGitLimit:专用于缓存包文件数据的堆内存的最大字节数。

默认值:10 m

增量基本缓存限制

deltaBaseCacheLimit:在增量基本缓存中缓存的最大字节数,用于膨胀的、最近访问的对象,没有增量链。

默认值:10 m

流文件阈值

streamFileThreshold:必须流式传输对象的大小阈值。

小于这个大小的对象可以作为一个连续的字节数组获得,而大于这个大小的对象需要使用一个ObjectStream。

默认值:50 m

使用虚拟内存映射

packedGitMMAP : true 允许在 windows 上使用 Java NIO 虚拟内存映射;false 使用标准读取调用将整个窗口读取到 byte[] 中。

默认值:未选中

未显示在首选项页面上

packedGitOpenFiles:一次打开的最大流数。打开包装计入过程限制。

默认值:128


† 感谢Jens TheeßMatthias Sohn 的答案的评论,其中包含指向源代码的指针。

于 2017-03-14T14:06:57.390 回答
2
  • 将窗口缓存限制增加到更大的值,它定义了用于将打包文件映射到内存中的 jgit 缓存的大小
  • 您是否在您的存储库上运行 gc(来自 egit 或本机 git)?JGit/EGit 不会自动运行它(还)。您可以在 EGit 的存储库视图中检查松散对象的数量(单击“属性”并选择“统计”选项卡)
  • 您的存储库有多少次提交(一年中的年龄没有说明任何内容,因为它可能有 10 年的年龄,有 2 次提交或 2 次 mio 提交)
  • 您使用的是哪个操作系统/文件系统?
于 2013-11-10T23:21:40.700 回答
2

EGit 3.5.0 将为大型存储库带来巨大的性能修复 - 无需“调整”任何东西。见https://bugs.eclipse.org/bugs/show_bug.cgi?id=440722

您可以使用每晚 EGit 构建更新站点来立即修复:http: //download.eclipse.org/egit/updates-nightly

于 2014-08-06T14:41:24.740 回答