To scale the Eclipse platform to a large product, plugin developers will at some point have to study both their CPU performance and their memory consumption.

Eclipse offers non-traditional performance challenges that have to do with the adoption of a large framework. It has been wisely coined that every Computer Science problem can be solved by adding one more layer of abstraction. The various Eclipse abstractions such as plugins, extension points, and features, allow developers to grow Eclipse to an unprecedented size. Some products include over 2,000 plugins. However, profiling tools typically only show low- level details that make it hard to rediscover the abstractions. For instance, one single API call in JDT may unwittingly result in millions of method calls if the workspace is large. Stack traces of 500-600 deep are not exceptional. How do we profile such large applications and make sure we don't get lost?

In addition to performance, memory consumption is highly relevant for Eclipse applications. Most Eclipse applications, including IDE extensions, are just in the business of converting data into different formats, such as from XML into a binary registry, Java source into class files, JSPs into Java and HTML, etc. Data conversion is often an expensive process, and plugin authors quickly resort to using a cache to play the space/time tradeoff game. Monitoring Java heap growth and doing blame analysis is far from trivial. It can be quite difficult to discover who owns a certain string when the heap measures 600MB and contains millions of objects.

What we will go over in this session is a set of publicly available profiling tools, and see how they can be used to profile Eclipse and analyze its heap usage and detect leaks. Various live demos will be given on real Eclipse scenarios and we will see how these profiling tools help address complexity.