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 回答