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 "Performance"

(Resources)
Line 32: Line 32:
 
----
 
----
 
[[Category:Performance]]
 
[[Category:Performance]]
Back to [[Eclipse Project]]
+
[[Category:Eclipse Project]]

Revision as of 14:59, 26 April 2007

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.

Scalability

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
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!
Algorithms
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.
Context
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.

Bugs

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

Resources

The Performance Bloopers page lists some common performance pit falls in Eclipse.

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

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.


Back to the top