Our work on NetBeans 6.7 is almost over and it is time to step back and ask ourselves what Fitness activities worked well, whether they delivered the expected results and what else shall be improved due to recent changes, rewrites and improvements.
Development vs. QA
Performance team often plays two roles: it can drive development of architecture related performance improvements or it can wear the QA hat and rather watch, report and request fixes over all teams. Due to heroic work described at Fitness67PressRelease, the performance team is now well positioned to play the role of QA: the scalability of "the only IDE you ever need, but never want to have" has been adressed. The "in the field" tools that help us track down the user problems are ready. The "year of annotations" gave us many new and effective ways to do declarative programming. The creation of parsing (and especially indexing) API removed the need to do exhaustive computation when the IDE starts. All of this were necessary initial developments to give NetBeans potential for further future improvements. All that is needed now is to do the boring step by step work of identifying problems, reporting bugs, requesting fixes - e.g. let the performance team act in QA mode.
- tests, whitelists, etc.
- tests to measure start time on more platforms (Linux, Solaris)
- automated tests to measure up-to-date checks
- measuring more project types (simple project, project with many project dependencies)
- automated tests to measure scanning time
- typing tests in editor
- automatic profile while AWT is blocked
The 6.7 release contains a lot of new functionality (parsing, new project types, feature on demand) which yet need to pass its test "in the field". It is expected that various performance related problems will be reported in the new areas and that the teams will have to spend time fixing them.
The nature of these problems may fall into two general categories. Either a fix will require local optimizations, or the whole infrastructure will require improvements to be better suited for effective use in a scalable environment.
- Java Editor & Parsing
- progress of background scanning?
- FoD improvements
See also specific Java & Editor performance tasks.
The "cut off" scalability achieved by FitnessForever can be seen as necessary initial performance boost enabler, yet it shall not be seen as the ultimate solution. We need to continue to improve our existing API registration mechanisms to provide better declarative registrations while all modules are enabled.
Addressing this goal implies further improvements in the architecture of our base IDE platform. UI presentation, parsing API registrations, various object factories need to be registered in a way that allows late instantiation - e.g. in a declarative way that delays the execution of custom code to the (distant) point when it is really needed.
- Declarative UI
- Winsys should not instantiate closed TC in sliding mode
- Why showing full toolbar/menu is more than 4s slower than ergo toolbar? Maybe IZ 13540 and others.
- Better registration for ToolsActions
- Do not scan shortcuts folder at startup
- ShortcutsFolder is too eager
- Navigator builds the panel content during TC open even when
- Multi selection of nodes and popup invocation in views is too slow - IZ 80723 and others
- Should avoid rebuilding shared subprojects
- Speed up XML processing in Window System and Settings
- Delete of 10000 nodes not indicated in UI
- Support editing of big files
There have been many problems reported in the area of scanning sources and indexing in Netbeans 6.7. In fact some of these problems have been in our codebase since Netbeans 6.0 when the new java infrastructure was introduced. The situation however escalated in 6.7 when we let poor quality code in the new indexing API, the infrastructure behind it and around the java indexer in the public milestone and beta releases. Although we have resolved most of these regressions the public perceptions of indexing in Netbeans is not good. We would like to improve this in Netbeans 6.8 and gain back the trust of our users.
We see three main areas for improvements and we would like to invest in all three of them in the Netbeans 6.8 release cycle. These areas are:
1. Speeding up indexing jobs and their parts
The general idea is that the faster indexing works the less noticeable and intrusive it is. Performance problems of various specific indexing tasks are tracked under the Editor / Parsing & Indexing category. There have already been identified obvious bottlenecks such as mime-types resolution (Issue 166340), pre-bundling index data for libraries shipped with the IDE (Issue 159756), batch processing of VCS generated events (Issue 167098), etc.
2. Making large rescans less intrusive
In some situations the IDE has to scan large amount of files. For example when a project is opened for the first time in the IDE or when indexing rules used by an indexer change (eg. the list of word patterns that are searched in the indexed files). These situation happen and can't be avoided. However, the IDE should still be usable even when the background scanning is on.
More specifically this means that user activities that do not need index data should not be affected by background indexing in any way. Also activities that may work reasonably well with obsolete (ie. old or stale) index data should not be affected (assuming that there are data from previous scans). This is going to be rather complex task with potentially many small improvements all over the IDE. We have an umbrella issue (Issue 133943) for tracking all the issues that fall in to this category.
3. Turning off automatic scanning and allowing manual refresh
This is a fundamentally different approach to indexing. Currently the IDE tracks all changes that happen in sources/libraries supplied by all opened projects (and their transitive closure) and updates indexes on-the-fly. This is good, because the indexes are always up-to-date. The drawback is that some changes can cause fairly large rescans that can take long time and negatively affect usability of the IDE.
This is typically not a problem of well structured projects with well defined dependencies, an example of this being Netbeans codebase. The real world projects however may be very different.
We have created an experimental module, which is now available on the autoupdate center, that turns off changes detection and automatic rescanning. Instead it provides 'Refresh All' action that can be used for manual refreshing of all indexes. The functionality of the module is very basic and we would like to improve it to the state when it could become part of the standard Netbeans distribution. Please see more details at Scan On Demand wiki page or in Issue 152749.