Featured in
Architecture & Design

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Operations & Infrastructure

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Enterprise Architecture

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Eclipse Performance Issues in Juno

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.

Maybe it is time to reconsider the yearly release cycle? This would allow the platform developers to more adequately test everything. As it is, I would expect next year's Eclipse to address all the problems in this year's, but somehow I doubt that as developers want to release features not bug/performance fixes.

> If eclipse goes to github, you'll never worry about lack of resources.

Big difference between having something slightly easier to grab the code and make changes and possibly provide some proposed update (GitHub .vs. SVN), and actually contributing worthwhile changes. Those exact same people, if they were really interested in providing feature X or feature Y could provide them with only slightly more effort with the current source code repo.

There is Eclipse 3.8 .. but it is not part of Eclipse release train. Eclipse 3.8 meant for bug fixes over 3.7 .. Now the main stream version of Eclipse is 4.2 .. Find more details about difference between Eclipse Juno release.

Sad but true... Why in order to receive bug fixes I should every year change finally polished and usable Eclipse 3.X.SR2 to new bunch of bugs? I just want bug fixes in WebTools, I do not need new "shiny slooow" UI, I do not want to download/update platform again and again.