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 reviewed API. As such it causes periodical regressions like 175932. As such the serverplugin maintainer needs to:
Change in the way installer and j2eeservers communicate. 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 report this as separate issue when 6.8 is over.
Unify Error Badging
Current implementation of error badges piggyback on masterfs API. This slows down I/O operations and does not scale (see JavaFX loaded on start). This shall be fixed by moving the error badge display to tasklist and making Java, JavaFX and co. talk to tasklist to tell it where the broken files are.
Faster Indication of Start
- Now, when the world almost completely switched to JDK6, we can use java -splash:filename.gif when launching NetBeans.
Responsiveness of the IDE just after startup
- We eliminated some tasks (or moved them out of AWT thread) to improve the responsiveness, but the IDE is still overloaded for some time after startup. Would be nice to do some further analysis and possibly do something about it.
Slowness detector improvements
- Special detection for editor responsiveness; e.g. code completion.
- Also create native dump if execution stays long in a native method (e.g. issues with slow painting).
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.
Feature on 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.
Scanning
- Despite all the work done for 6.8 there are still things to improve, cases people complain about... We want to go in two direction: reducing and speeding up the scanning itself, and making the scanning less intrusive so the IDE can be used during scanning in more situations. Would like to go towards the transactional index idea.
Other
- Reliable and fast detection of file changes (mainly external).
Document good practices for developers
- Summarize 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.
