Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Platform UI/Juno Performance Investigation"

(Resources)
(Resolution)
(21 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Several users are reporting performance problems when using the Juno release. Here is a summary of what we know and what is being done to resolve them.
+
Many users have reported performance problems when using the Juno (June 2012) release. This page contains a summary of the problems found and how they were addressed.
 +
 
 +
= Resolution =
 +
Several major performance defects have been addressed in Juno SR2 (4.2.2). Community members have confirmed that these fixes substantially address the performance problems with editor and view opening, closing, and switching. These fixes are widely available in [http://download.eclipse.org/eclipse/downloads/drops4/R-4.2.2-201302041200/ Juno Service Release 2 (February 2013)]. All defects are also resolved in the Kepler (June 2013) release stream.
  
 
= Symptoms =
 
= Symptoms =
Line 7: Line 10:
 
* There are mixed reports of changing JVM version, vendor, or command line arguments improving the situation, but with no definite pattern
 
* There are mixed reports of changing JVM version, vendor, or command line arguments improving the situation, but with no definite pattern
 
* Often but not always the slowness occurs with JEE or Android editors
 
* Often but not always the slowness occurs with JEE or Android editors
* Similar symptoms are seen by both JGit and Subversion users, but not CVS so far
+
* Similar symptoms are seen by users of various team providers
 
* Reverting platform version to Indigo with all other plugins the same, usually resolves the problem
 
* Reverting platform version to Indigo with all other plugins the same, usually resolves the problem
  
Line 14: Line 17:
 
The problems seem to fall into two general categories:
 
The problems seem to fall into two general categories:
 
# Small but noticeable degradation in UI performance between 3.7 and 4.2 platform code base. For example in a fresh new workspace, opening an editor taking 100ms rather than 50ms. These problems are known and slow/steady progress is being made on improving it. In general these problems are due to having a completely new code base for the platform user interface. The 3.x platform had many years to optimize the critical code paths, and these optimizations will take time to make on the 4.x stream over the coming releases.
 
# Small but noticeable degradation in UI performance between 3.7 and 4.2 platform code base. For example in a fresh new workspace, opening an editor taking 100ms rather than 50ms. These problems are known and slow/steady progress is being made on improving it. In general these problems are due to having a completely new code base for the platform user interface. The 3.x platform had many years to optimize the critical code paths, and these optimizations will take time to make on the 4.x stream over the coming releases.
# Extreme degradation of performance, such as 3-4 seconds to open/close editors. These problems typically only occur after prolonged usage, and in conjunction with certain plugins. The Eclipse platform committers have not yet reproduced these problems but some leaks have been identified that could be contributing to it. It is quite possible that leaks in the platform code, in conjunction with expensive listener computations in contributed plugins, combine to manifest the problem.
+
# Extreme degradation of performance, such as 3-4 seconds to open/close editors. These problems typically only occur after prolonged usage, and in conjunction with certain plugins. These were not reproducible using the plain Eclipse SDK, but manifest themselves in certain Eclipse packages and with  certain user workflows. These problems were narrowed down to leaks or excessive events in the platform code, in conjunction with expensive listener computations in contributed plugins, combining to manifest the problem.
  
 
= Plan =
 
= Plan =
  
The main focus over the coming months will be making performance fixes in the Juno stream. As the basis of the Eclipse Long Term Support program, the Juno stream is very important to stabilize and improve. A small set of fixes were made for Juno Service Release 1, arriving this week. Further fixes will target Juno Service Release 2 (February 2013). Builds towards Juno SR2 occur every week and will start next week (October 3). Changes that are considered too risky for the service stream will be made in the Kepler stream (June 2013 release).
+
The main focus is on making performance fixes in the Juno stream. As the basis of the Eclipse Long Term Support program, the Juno stream is very important to stabilize and improve. A small set of fixes were made for Juno Service Release 1. Further fixes will target Juno Service Release 2 (February 2013). Builds towards Juno SR2 occur every week - see the '''4.2 Maintenance Build''' section on the [http://download.eclipse.org/eclipse/downloads/ download page]. Changes that are considered too risky for the service stream will be made in the Kepler stream (June 2013 release).
 +
 
 +
Community help is needed to test the fixes and report further problems. Many of these issues were only reported after the Juno release came out, and those who can reproduce the problems have been providing great input since then. We strongly encourage adopting Juno SR2 maintenance builds and verifying fixes, reporting further problems, and assisting with profiling and tests to narrow down the problems.
 +
 
 +
Some progress is being made towards running automated performance tests for the first time at eclipse.org. Test builds are running today, but it will be awhile before we have tools ready to extract and analyze the results. Anyone willing to help with writing performance testing infrastructure please get involved in {{bug|374441}}.
  
Community help is needed to test the fixes and report further problems. None of these issues were reported before the Juno release came out, and those who can reproduce the problems have been providing great input since then. We strongly encourage adopting Juno SR2 maintenance builds and verifying fixes, reporting further problems, and assisting with profiling and tests to narrow down the problems.
+
We do understand there are commercial Eclipse adopters who are not yet ready to migrate to the 4.2 release, for either performance or other reasons. On the other hand, the Eclipse Platform and releng team needs to focus its resources on one active stream, and we are confident that with community help we can advance 4.x to a point where it is acceptable for all. Contributions in the form of problem reports, test cases, and patches are essential for good progress to be made.  
  
We are not considering any further 3.x releases.
+
We are not considering any further 3.x releases after the 3.8.2 maintenance release scheduled for February 2013, though the code base and Eclipse.org build infrastructure will of course remain available for others who see a need to step up and maintain that stream.
  
 
= Further Reference =
 
= Further Reference =
  
 
* {{bug|385272}}
 
* {{bug|385272}}
 +
* [https://bugs.eclipse.org/bugs/buglist.cgi?keywords=performance&keywords_type=allwords&list_id=3048745&resolution=FIXED&classification=Eclipse&query_format=advanced&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&product=JDT&product=PDE&product=Platform&target_milestone=3.8.1&target_milestone=4.2.1 Bugzilla query of performance fixes in Juno SR1]
 +
* [https://bugs.eclipse.org/bugs/buglist.cgi?keywords=performance&keywords_type=allwords&list_id=3048750&resolution=FIXED&classification=Eclipse&query_format=advanced&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&target_milestone=3.8.2&target_milestone=4.2.2&product=JDT&product=PDE&product=Platform Bugzilla query of performance fixes in Juno SR2]
 +
* [https://bugs.eclipse.org/bugs/buglist.cgi?keywords=performance&keywords_type=allwords&list_id=3048755&resolution=FIXED&classification=Eclipse&query_format=advanced&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&target_milestone=4.3&target_milestone=4.3%20M1&target_milestone=4.3%20M2&target_milestone=4.3%20M3&target_milestone=4.3%20M4&target_milestone=4.3%20M5&target_milestone=4.3%20M6&target_milestone=4.3%20M7&target_milestone=4.3&product=JDT&product=PDE&product=Platform Bugzilla query of performance fixes in Kepler] (All Juno performance fixes will also appear in Kepler)

Revision as of 10:43, 14 May 2013

Many users have reported performance problems when using the Juno (June 2012) release. This page contains a summary of the problems found and how they were addressed.

Resolution

Several major performance defects have been addressed in Juno SR2 (4.2.2). Community members have confirmed that these fixes substantially address the performance problems with editor and view opening, closing, and switching. These fixes are widely available in Juno Service Release 2 (February 2013). All defects are also resolved in the Kepler (June 2013) release stream.

Symptoms

  • Symptoms are slow UI operations such as open and closing views/editors/perspectives
  • Often the degradation only happens after prolonged usage, or when certain plugins are installed
  • There are mixed reports of changing JVM version, vendor, or command line arguments improving the situation, but with no definite pattern
  • Often but not always the slowness occurs with JEE or Android editors
  • Similar symptoms are seen by users of various team providers
  • Reverting platform version to Indigo with all other plugins the same, usually resolves the problem

Analysis

The problems seem to fall into two general categories:

  1. Small but noticeable degradation in UI performance between 3.7 and 4.2 platform code base. For example in a fresh new workspace, opening an editor taking 100ms rather than 50ms. These problems are known and slow/steady progress is being made on improving it. In general these problems are due to having a completely new code base for the platform user interface. The 3.x platform had many years to optimize the critical code paths, and these optimizations will take time to make on the 4.x stream over the coming releases.
  2. Extreme degradation of performance, such as 3-4 seconds to open/close editors. These problems typically only occur after prolonged usage, and in conjunction with certain plugins. These were not reproducible using the plain Eclipse SDK, but manifest themselves in certain Eclipse packages and with certain user workflows. These problems were narrowed down to leaks or excessive events in the platform code, in conjunction with expensive listener computations in contributed plugins, combining to manifest the problem.

Plan

The main focus is on making performance fixes in the Juno stream. As the basis of the Eclipse Long Term Support program, the Juno stream is very important to stabilize and improve. A small set of fixes were made for Juno Service Release 1. Further fixes will target Juno Service Release 2 (February 2013). Builds towards Juno SR2 occur every week - see the 4.2 Maintenance Build section on the download page. Changes that are considered too risky for the service stream will be made in the Kepler stream (June 2013 release).

Community help is needed to test the fixes and report further problems. Many of these issues were only reported after the Juno release came out, and those who can reproduce the problems have been providing great input since then. We strongly encourage adopting Juno SR2 maintenance builds and verifying fixes, reporting further problems, and assisting with profiling and tests to narrow down the problems.

Some progress is being made towards running automated performance tests for the first time at eclipse.org. Test builds are running today, but it will be awhile before we have tools ready to extract and analyze the results. Anyone willing to help with writing performance testing infrastructure please get involved in bug 374441.

We do understand there are commercial Eclipse adopters who are not yet ready to migrate to the 4.2 release, for either performance or other reasons. On the other hand, the Eclipse Platform and releng team needs to focus its resources on one active stream, and we are confident that with community help we can advance 4.x to a point where it is acceptable for all. Contributions in the form of problem reports, test cases, and patches are essential for good progress to be made.

We are not considering any further 3.x releases after the 3.8.2 maintenance release scheduled for February 2013, though the code base and Eclipse.org build infrastructure will of course remain available for others who see a need to step up and maintain that stream.

Further Reference

Copyright © Eclipse Foundation, Inc. All Rights Reserved.