In an email thread on Eclipse performance issues in Juno (Eclipse Platform 4.2) Eclipse silver sponsor Cloudsmith cofounder Thomas Hallgren has kicked off a flurry of dialog. Hallgren, an active committer on the Eclipse b3 project, says that after switching back from version 4.2 to version 3.8: "I was stunned by the performance improvement after the switch. The 3.8 platform is much MUCH faster"
The Eclipse Bugzilla entry for bug 385272 ("Very slow response after upgrade to Juno Release") is replete with commentary. When 4.2 is first launched things are fine, according to some of the postings. However the performance progressively degrades as it runs. Some users have reported that restarting Eclipse can temporary restore it to a desirable performance level.
Eclipse executive director Mike Milinkovich in his "Life at Eclipse" blog says this is nothing new and attributes it to a lack of resources. "The performance tests were turned off because the Eclipse platform team has a serious resource issue. The simple fact of the matter is that the Eclipse platform team is stretched well beyond what it can reasonably be expected to accomplish. This is not a new problem. It has been discussed in many forums for at least the past three or four years. Unfortunately, very few people or organizations have stepped up to make significant contributions."
InfoQ solicited Milinkovich for some additional details:
InfoQ: Is there is a projected date for a fix in Juno or do we need to wait for Kepler (Eclipse Platform 4.3)?
Milinkovich: The team's focus for Juno was on stability, function, and compatibility. Prior to release, there was no significant hue and cry about performance.
Now that we have known issues, the team will be addressing them as soon as possible. There is one known memory leak fixed in SR1 coming in a few weeks. There will certainly be others fixed in SR2 in February. So we do expect significant improvements before Kepler, and in Kepler itself.
To keep this in some perspective, the amount of community reaction was, in fact, significantly larger when we shipped Eclipse 3.0 in 2004. It is not unusual to have problems when you undertake a major overhaul of a platform as widely used as Eclipse.
We are looking at all cases that have been identified and are trying to make progress on as many of them as possible. The only way of uncovering and fixing those issues is by actually using Juno, reporting issues, and investigating them. There will not be an Eclipse 3.9, and all new features and performance enhancements will take place in the 4.2 and 4.3 streams.
InfoQ: Can you explain the role the Eclipse foundation plays in Eclipse's development.
Milinkovich: Our role has not been to lead development but to host the projects and to ensure the smooth operation of the Eclipse development and IP processes. We do not staff developers or architects at the Eclipse Foundation. It is the responsibility of each project to meet the needs of its users and adopters. The community can help enormously by providing good feedback, re-usable test cases and patches.
Historically, contributing to the Eclipse platform project has been relatively complicated. We are hopeful this will change soon. Improvements such as switching to GIT, starting to use the common build infrastructure (based on Maven and Tycho), and the much more approachable Eclipse 4 code base will, we hope, all combine to significantly enhance the ability of the community to contribute.