PostNB68PerfTopics

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

Reliable detection of external file changes

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.

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

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)

Documentation

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.