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.
Poor performance is a bug and should be tested for, tracked and fixed in the same way as other bugs. This page is a collection of resources and information aimed at helping plug-in developers do just that.
Most performance bugs are an issue of scalability. Code is typically written and tested against toy data and simple test cases. In the field, the data being operated on can be 10x or 100x larger, where poor algorithms and design are quickly exposed. When writing code, you always need to ask, "What would happen if the sample size was 10x larger?" Ten times more plug-ins, more resources, more windows, menus, perspective, markers, etc.
Where can you find improved scalability?
- Plug-in startup time
- There is more to startup time than just how long it takes the Eclipse workbench to come up. If your plug-in is slow to start, users have to wait for your function. This may happen at any point in a session. Plug-ins that start too early, needlessly activate others, load too much code and/or do too much work when first activated work against scalability.
- Footprint affects scalability as bloated, memory hungry applications tax the workstation's resources causing the system as a whole to slow down. Understand the space you are using. Do you need all that information? All the time? For all the elements? Is there a more efficient structure? Count the bytes!
- Look for algorithmic improvements. Change the approach to the problem and you may get 2x, 5x or even 10x improvements. When N is small, speed is easy.
- Understand the whole picture. What does it mean to use some API provided by others. Some apparently simple functions may require megabytes of code/data to be loaded or seconds/minutes of computing to be done. Even if it's not your API it's still your problem if you are the one triggering it.
Always enter a bug when you encounter things in Eclipse that are slow or that seem to scale poorly. The performance keyword should be added to make it easier to track and search for performance bugs. To see the current list of open bug reports, run this query
The Performance Bloopers page lists some common performance pit falls in Eclipse.
The Performance Test Fingerprint Guidelines page explains which performance tests should be in the fingerprints
The Performance3.3 page lists performance issues addressed during the Eclipse 3.3 performance milestone.
The Big Workspace test data can be used to help identify problems caused by poor scalability
Eclipse/Testing#Profiling_performance_tests provides instructions on how to run automated performance tests with a headless profiler agent attached to it. This is a very useful way to peek inside your performance test and see exactly where the time is going.
The How to Write Performance Tests page explains how to write test cases that monitor performance.
Various teams have created tools to monitor/track the behavior of their plug-ins. Home pages for the tools are listed below. Some may be a little rough but generally they provide information useful in tracking down bugs and performance problems. More are being added all the time.