With NetBeans 6.8 almost complete we start thinking about future - what performance issues we should attack in next releases. This page collects performance topics and ideas that we think are actually most important for our users, and what we could do to improve the IDE performance in various aspects (UI responsiveness, scalability).

Note: This page is not a plan, just an area for gathering ideas. It's changing, things being added... 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 PostNB67PerfTopics, PostNB65PerfTopics.

More robust and performant registration of GlassFish & co.

The registration of servers is flawed and not properly reviewed API. As such it causes periodical regressions like Issue 175932. To eliminate such problems and also make the registration more performance and installer friendly, the following shall happen:

Change in the way installer and serverplugins communicate when installing Tomcat and Glassfish. It seems that right now the installer sets a property in etc/netbeans.conf and various j2eeservers, when started, use this property and write something into $userdir/config/GlassFish, etc. This is flawed from performance point of view (the modules do some work on start, sooner then user needs to use them) as well as unnecessary complicated.

We need the installer to create the file directly in nb6.9/config/GlassFish directory. Let's track this as Issue 179249.

Related problem is that the system is incapable to recognize a registration without querying all registered serverplugins. Again, it is desirable to have some mapping between registration and serverplugin and load just the desired one.

Unify Error Badging

See the FitnessForErrorBadges proposal.


Faster Indication of Start

  • Issue 60142: Now, when the world almost completely switched to JDK6, we can use java -splash:filename.gif when launching NetBeans.

Reliable detection of external file changes

  • Issue 26230: Native listening on file changes (for recursive FS listener implementation)

Effective Common Ground

The NetBeans 6.9 is supposed to reuse common components available elsewhere. This is expected to create a pressure on performance of the whole system and performance team will have to dedicate some work to eliminate such negative impact.

Compact NBM files

Responsiveness of the IDE just after startup

We eliminated some tasks (or moved them out of AWT thread) to improve the responsiveness, but according to some reports the IDE is still overloaded for some time after startup. Would be nice to do some further analysis to either confirm or dispel this issue.

Slowness detector improvements

  • Special detection for editor responsiveness:
    • code completion,
    • Go to Type dialog.
  • Also create native dump if execution stays long in a native method (e.g. issues with slow painting).

"Scanning" Issues

  • ParsingAPI to use addRecursiveListener (for reliable and fast detection of file changes, mainly external).
  • Despite a lot of work done for 6.8 there are still things to improve, issues people complain about... It makes sense to continue in two directions: reducing and speeding up the scanning itself, and making the scanning less intrusive so the IDE can be used during scanning in more situations IDEUsableWhenScanning).
  • Specific issues found by the code completion or Go to Type profiling...

Scalability of Parsing Related Infrastructure

  • During testing 6.8 we have seen more and more evidence that the parsing, refactoring and especially CSL infrastructure does not scale. The effect of this is slightly suppressed by FoD, however we still initialize JavaScript when one wants to use CSS or PHP or we consult Scala when one needs to refactor Java code. This useless work needs to be eliminated by better registration schemes in various parsing related parts. Only then the user will benefit from instant reply and fast edit/complete/refactor cycles.

Refactoring improvements

  • No big optimizations happened since parsing API rewrite, good potential was seen when fixing some regressions in 6.8.

Features Off Demand

  • Turning off unused features. Some clusters could work in a mode that if not used for certain time, they'd be disabled on IDE shutdown, next time available via FoD just like after first start. This is highly desirable for cases when people just try various features but don't in fact use them afterward.
  • Move (part of) FoD layers from the central place to modules for better transparency and maintainability (research area)


  • Good practices for developers, e.g. how to solve UI responsiveness issues from the Slownes Detector - create a wiki page summarizing the options and what to do if the UI needs to be blocked (replanning out of AWT, using progress API, showing wait cursor, showing modal dialog, etc). See also Run Off AWT.
  • Update/move docs under NetBeansDeveloperFAQ.
  • Update docs about performance criteria and rules we want to follow in NetBeans.
  • How to use slowness detector and UIGesturesCollector in platform based applications
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