This is a overview of suggested performance improvements (goals) for NetBeans 6.5. See the implementation plan for more details.
- Keep the startup improvements from 6.1 - don't regress (with growing IDE and new features).
- Improve UI responsiveness of Projects Explorer - navigation.
- Try to improve the user experience with initial scanning (indexing files) and updating on changes.
- Keep the overall UI responsiveness - don't regress (85% of automated tests pass).
- Continue extending test infrastructure.
This part collects specific tasks planned for NetBeans 6.5 that would improve performance of the IDE in various areas. The tasks go across many NetBeans teams; don't include regular bug fixing.
UI Responsiveness of Projects Explorer (Navigation)
Make navigation in explorer faster and smoother - lower time to expand packages, faster repetitive selection changes.
- P2: Rewrite DataLoader's registration and use - make file recognition faster, based on mime type. IZ 91665, more details
- P3: Lazy explorer - effectively process only the actually visible content. More details
- P3: Fast Sources Packages expansion - reusing data from scanning. IZ 134555
- P2: Scalable debugging for enterprise - avoid many debugger types (we have about 10 debuggers) to have their own listeners on everything changing in the IDE, implement efficient registration and listening. IZ 133682
- P2: Fix performance of versioning filesystems - make the UI performance of a versioned filesystem comparable to a local filesystem (max 30% slower in UI responsiveness). More details.
Java Infrastructure and Editing
- P2: Do complete measuring and analysis of java editor and java infrastructure (editor speed & UI responsiveness, scanning speed, several refactoring scenarios, tests).
- P2: Start scanning of project classpath after all projects are opened - projects will open faster, will have complete classpath sooner (e.g. for the Go to Type dialog), avoiding lots of events about classpath modification during project opening, simpler and better defined procedure of opening a project, potentially less work done. IZ 67270
- P3: More efficient up-to-date scanning (raw performance optimization) - to shorten the time the IDE scans after start to check for source changes (when mostly nothing is changed). IZ 108159
- P2: Navigation working and responsive during up-to-date scanning - at least Go to Type dialog and Ctrl-click in editor. IZ 133943
- P3: File changes events coalescing - avoid repeated re-indexing/re-compiling when multiple files are modified during a longer operation - e.g. cvs update or refactoring.
- P3: Measure and optimize java refactoring, cover with tests to quantify concrete improvements, secured against regressions. (There's a potential for optimization, but concrete scenarios and improvements need to be discovered first.) IZ 133914
Related: There is a new parsing framework under way for 6.5 which should unify parsing of various languages in the IDE, eliminate duplicated code, solve threading issues, and also improve performance of some editor features and scalability in many situations. However, there will also be a negative impact on initial scanning that will have to do more work (all files will be indexed). The tasks in this paragraph are to compensate for this impact.
Building & Running
- P2: Compile on save - incremental compilation of java files every time a file is saved; should speed up time to run a project or file (i.e. test changes). IZ 132165
- P3: Faster building of complex (enterprise) projects - with multiple dependencies on a common project. The current compilation with ant exposes the problem with bigger projects - does not scale. IZ 42683
No significant improvements in startup time planned. Must prevent regressions.
- P2: White list of classes loaded during startup - new test, supplement black list (already implemented) to gain control over what's happening during startup; thoroughly monitor additions.
Go after memory leaks systematically and with regression tests.
- P2: Make sure closed projects (P2) and closed document views (P3) don't leak, make part of commit validation.
- P1: Rewrite automated perf test infrastructure - migration from test4u and xtest. More details
- P2: Common dashboard fixes - adding cold start, easy comparison between builds, visualization of regressions, etc.
- P2: New UI tests - e.g. for scripting.
- P2: New types of tests - continue extending tests infrastructure to cover more performance problems and protect against regressions. E.g. white list of classes, refactoring scenarios, scanning, more TBD.
Start a serious discussion about future growth of the IDE - with regards to performance. FeatureOnDemand still seems to be the only efficient weapon.
Note to priorities
- P1: Must have feature - no way not to do it for the release.
- P2: Target feature - planned for release and staffed, but not critical.
- P3: Nice to have - would like to do if possible, but requires more investigation or is too risky/unclear so can't be confirmed at this moment (can't say if really doable).