Revision as of 08:42, 28 May 2010 by Tpavek (Talk | contribs)

As usual with every release, when finishing NetBeans 6.9 we start thinking about what performance issues to attack in next releases. This page collects performance topics that are actually most important for our users, and ideas about what we could do to improve the IDE performance in various aspects (UI responsiveness, scalability).

Note: This page is not a plan yet, just an area for gathering ideas. If you have any idea or see an important problem, just throw it here. We'll finalize the content, prioritize and select specific topics as part of next release planning. See also previous PostNB68PerfTopics, PostNB67PerfTopics, PostNB65PerfTopics.

Indexing and parsing infrastructure

Scanning-related issues are still at the top of complaints about performance from our users. No performance improvements were planned for 6.9, there were some regressions solved and a few partial improvements (bug fixes). It is now important to do more in this area again.

As usual, we can try to make things faster, more efficient and scalable, but we should also pay more attention to making the IDE work better for the user. That is for example making the IDE usable even during scanning, with main features always available and responsive, no matter the amount or speed of the scanning running meanwhile.

Go to Type/Go to File (navigation)

Responsive navigation is essential for perceived performance of the IDE. Despite various improvements in the past, it is still not as good as it should be. General requirements:

  • fast, not influenced by other work the IDE is doing on background,
  • available as soon as possible (after startup, when opening a project), even with partial results.

Ad speed: We have bug 177274 to track reports of slow response of Go to Type. Several fixes have been made already, more are needed. The speed should be "as you type". E.g. there is the possibility to move the index into memory, which would make the access faster.

Ad availability: There are significant delays when trying Go to Type soon after startup or when opening a project. E.g. after startup all projects must be opened first, then indexing (up-to-date check) goes through the projects. Even if the infrastructure can provide index for Go to Type/Go to File before complete scanning is finished, the user project, from which the user most likely wants something to open quickly, is processed as last. Would be great if the index availability was independent on state of projects opening/scanning. There's an idea of a more independent "mega index" that might allow this.

Code completion, find usages, etc

Code completion and other operations requiring java source infrastructure (not modifying sources) have similar general problems as navigation -- speed and availability.

There's bug 179727 for tracking reported slow code completion.

Availability is even worse than Go to Type/Go to File. It's not available at all if any scanning is in progress. Besides the initial scan, it should just work with the latest data available, even if some scanning needs to run at the same moment. There as an idea of "transactional index" that should allow this mode.

Other notes to scanning

  • Lots of slowness is also due to I/O contention. Ideally all I/O but the one serving immediate user request should be temporarily stopped in the IDE. Introducing "idle I/O"...
  • There are known inefficiencies in the way projects and Java infrastructure work together, how the classpath is composed and updated, how queries work... Besides speed, one manifestation is the inability to fix the infamous "scanning started when project is closed" (related to GlobalPathRegistry).
  • Check for up-to-date indexes is needlessly loading all providers (besides it's not working correctly for projects reopened later - bug 180262).
  • Indexing infrastructure does not scale to size of real C++ projects (tens of thousands of files). TBD in what metrics exactly insufficient.
  • CND team developed their own infrastructure for Go to File/Go to Type for C++ projects. It's known to be faster than in NB. We should investigate how to combine both to get better results, perhaps also reduce duplicated functionality.


Really big files are required to be editable in the IDE, e.g. C++ or XML. The IDE cannot handle well files bigger than ~1MB.

The new "view hierarchy" being prepared (e.g. for the word wrapping feature) is also a potentially big risk for editor performance.

Native file listeners

Detecting external file changes introduced in late 6.8 and used in 6.9 is rather provisional. There's an agreement it needs to use native listeners instead of crawling all the files when IDE gains focus. It would improve performance and reliability, it's also the only way to recognize all changes correctly.

Performance tab in Options

There are various settings and switches that affect performance of the IDE in various ways. People often don't know about them. Would be nice to have a dedicated tab for performance in Options for that.

Some examples what could be configured here:

  • automatic checking for external changes,
  • scope of scanning after change in a file,
  • memory settings, e.g. max heap or max perm. gen. size,
  • self profiling setting,
  • Lucene indexes in memory.


  • Performance optimizations for Equinox (mainly startup).
  • Self-profiling available for platform introduced some performance problems, e.g. bug 185688, bug 186690. Perhaps should consider to use the original sampler available in profiler, if profiler is part of the IDE run by user.


Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo