我发现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 here中找到了以下引用:
... EGit必须公开UI以允许用户在处理时进行配置 更大的存储库。
听起来很适合我的情况。所以我在eclipse中环顾四周,在Window -> Preferences -> Team -> Git
下找到了这些Git Window Cache设置:
但我该如何使用它们?
不同的控制实际上做了什么?有没有人能够通过使用它们来提高EGit的响应能力?
答案 0 :(得分:2)
答案 1 :(得分:2)
EGit 3.5.0将为大型存储库带来巨大的性能修复 - 没有"调整"任何东西。见https://bugs.eclipse.org/bugs/show_bug.cgi?id=440722
您可以使用每晚的EGit构建更新站点立即获得修复: http://download.eclipse.org/egit/updates-nightly
答案 2 :(得分:2)
作为Matthias Sohn suggested,窗口缓存限制似乎是这些参数中最重要的。
对我来说,增加这个来自" 10 m"至" 500米"对自我的反应如何产生了巨大的影响。
来自WindowCacheConfig.java的源代码†:
packedGitWindowSize :从包文件映射或读入的单个窗口的大小(以字节为单位)
默认值:8 k
packedGitLimit :专用于缓存包文件数据的堆内存的最大字节数。
默认值:10米
deltaBaseCacheLimit :对于没有增量链的膨胀的,最近访问的对象,在增量基础缓存中缓存的最大字节数。
默认值:10米
streamFileThreshold :大小阈值,超出该阈值的对象必须流式传输。
小于此大小的对象可以作为连续的字节数组获得,而大于此大小的对象需要使用anObjectStream。
默认值:50米
packedGitMMAP :true允许对Windows使用Java NIO虚拟内存映射; false使用标准读取调用将整个窗口读入byte []。
默认值:未选中
packedGitOpenFiles :一次打开的最大流数。打开包装会计入过程限制。
默认值:128
†感谢Jens Theeß对Matthias Sohn's answer的评论,其中包含指向源代码的指针。