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"

m (Resources: https://bugs.eclipse.org/bugs/show_bug.cgi?id=390820)
 
(6 intermediate revisions by 3 users not shown)
Line 19: Line 19:
 
== Resources ==
 
== Resources ==
 
The [[Performance Bloopers]] page lists some common performance pit falls in Eclipse.
 
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 [[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
 
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.
 +
 +
[http://www.asktog.com/basics/03Performance.html Article on user perception of performance]
 +
 +
The [[Performance/Automated Tests|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.
 
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.
 +
  
 
* [http://eclipse.org/eclipse/platform-core/documents/3.1/perf_stats.html Performance gathering APIs]
 
* [http://eclipse.org/eclipse/platform-core/documents/3.1/perf_stats.html Performance gathering APIs]

Latest revision as of 18:19, 15 March 2014

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 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.

Article on user perception of performance

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.



Copyright © Eclipse Foundation, Inc. All Rights Reserved.