在一场关于 Eclipse Juno 版本性能问题的邮件讨论(email thread)中,Eclipse 的白银赞助商同时也是Cloudsmith 的共同创始人Thomas Hallgren 开启了一波对话。作为 Eclipse b3 项目的活跃提交者,Hallgren 说将 4.2 版本切换回 3.8 版本后,“震惊于切换后的性能提升。3.8 版本的平台要快得多得多(much MUCH faster)”。
Eclipse 缺陷管理工具 Bugzilla 上的 385272 缺陷(升级到 Juno 发布版后,响应非常慢)条目上,充满了评论。按照一些回复的说法,当 4.2 刚刚启动的时候,一切安好。但是,随着它的运行,性能逐渐下降。一些用户报告说,重新启动 Eclipse 能够临时恢复到令人满意的性能水平。
Eclipse 的执行董事 Mike Milinkovich 在其名为“Eclipse 生活”(Life at Eclipse)的博客中提到,这并不是什么新鲜事,并将其归因为缺乏资源。“因为Eclipse 有严重的资源问题,性能测试就被停掉了。这个问题的实际情况是Eclipse 平台团队的扩张超出了他们按期正常交付的能力。至少在最近的三四年中,这个问题已经在很多论坛中讨论过了。遗憾的是,很少有人或组织来对此做出有意义的贡献。”
InfoQ 和 Milinkovich 了解到了更多的信息。
InfoQ:会有一个可预计的日期来修正 Juno 版本,还是我们要等待 Kepler 版本(Eclipse 平台 4.3)呢?
Milinkovich:Juno 团队的关注点在稳定性、功能以及兼容性上。在发布前,并没有关于性能方面的抱怨。
既然我们已经知道了问题,那团队会尽快解决。在未来几周的要发布的 SR1 中,会修正一种内存泄露的问题。在二月份发布的 SR2 版本中肯定会包含其它问题的修正。所以我们希望在 Kepler 版本之前及 Kepler 版本中会有明显的提升。
以下事实为我们的观点提供了支持,当我们 2004 年推出 Eclipse 3.0 的时候,实际上社区的反应比现在大得多。当你对像 Eclipse 这样广泛使用的平台进行大规模改造的时候,有些问题会很常见。
我们查看了所有发现的问题,并会尽可能多地处理它们。发现并解决这些问题的唯一途径就是实际使用 Juno、报告问题并对其进行审查。我们不会发布 3.9 版本,所有新的功能和性能提升都会在 4.2 和 4.3 的代码流中进行。
InfoQ:你能介绍一下 Eclipse 开发中,Eclipse 基金会所扮演的角色吗?
Milinkovich:我们的角色从来就不是领导研发,而是托管这些工程并保证 Eclipse 研发的顺利进行和工业生产过程( IP processes)。在 Eclipse 基金会中我们没有雇佣开发人员或架构师。满足用户和相关采纳者的需求是各个项目的责任。社区能够提供极大的帮助来提供良好的反馈以及可重用的测试用例和补丁。
一直以来,为 Eclipse 平台项目贡献功能相对来讲比较复杂。我们希望这能很快得到改观。我们的一些改进诸如切换到 Git、开始使用通用的构建设施(基于 Maven 和 Tycho)以及更易访问的 Eclipse 4 代码都是希望能够明显增强社区贡献的能力。
评论