NetBeans 6.7 Performance Topics
This page is here to collect important performance issues and ideas what to improve for the next NetBeans release (after 6.5). It will be used for planning performance work on the next releases. For the next release we'll try to select the most important topics. For now the list is open for discussion.
Feel free to fill in whatever you think is important and should not be missed. We welcome concrete problems and as many details as you can give, link IZ issues, include suggestions of solution, etc. The format is not important, this page is for collecting raw data. You can follow the suggested structure, add your issues, add notes to existing issues, create your own paragraphs, etc.
Please always try to justify the issues or improvement from the user point of view, make sure it is clear where the problem is visible, how many people it is relevant to, etc. Please also specify the importance (P1 - critical, P2 - desirable for next release, P3 - important, but not with broad impact). You can also be inspired by performance problems we collected about a year ago.
P3: Farther improve the cold startup time. It is still much longer than warm startup, and perceived as a problem.
P2: The IDE should be better usable after startup. Ideally fully functional and responsive immediately. Or perhaps there should be clear indication when it is ready with all projects/files opening and scanning finished. We should avoid the Windows XP syndrome. See e.g. IZ 144426, IZ 150875.
Size of IDE, scalability
P2: The IDE is too big and still growing. Nobody is able to use all the features. There are many areas where unused features cause problems: startup time, additional loaded classes, registrations on various places slowing down operations needlessly (e.g. refactoring, selection changes, context menus), more bugs, UI clutter. Our users often complain the IDE is a "hog", but most people are not aware of the penalty they pay when downloading the full IDE distribution and that there is a way to have much lighter IDE. We need some mechanism which would get the size of IDE under control and still allow to get to any available functionality easily. More details
P2: Navigation (Go to Type, Go to Source) should always be fast, regardless if java infrastructure needs to perform some heavy scanning at the same time.
P2: Go to File should be much faster. People expect it to be the same as Go to Type feature. Building a file index is likely needed. See also IZ 147620.
P2: Search in files is slow, much slower than from cmd line, hardly usable in large projects. See also IZ 134558.
P2: Need to finish the Parsing API project. With many non-java languages supported there is a need to unify the infrastructure that handles parsing and updating metadata about sources. Currently there are duplications in large areas of code, several parsing threads doing their work uncoordinately, causing various problems including performance and scalability issues. More details
P2: The IDE is unusable during scanning. This can be quite visible because the scanning often seems too aggressive (due to bugs, wrong setup, large projects, sources on network, etc). User experience could be much improved if we managed the java infrastructure to:
- Allow to use "old" metadata for some operations so they don't need to wait for scanning finish - navigation, code completion (but e.g. not for refactoring).
- Stop scanning to perform user tasks preferentially - navigation and code completion should react immediately (backed by the same infrastructure), but perhaps also file searching or file opening could be given a preference. The problem with scanning is that it blocks other I/O intensive operations which can't be solved just by giving the parsing thread a low priority.
- Suspend scanning for VCS updates when many changes are coming in for long time period and repeated rescans would just slow everything down.
See e.g. IZ 133943.
P2: Why is startup with one project slower than the one without any project? IZ 150194
P2: Finding usages is too slow, mainly compared to competition. There is a chance it could be improved significantly. Other refactorings that search for usages would benefit as well, e.g. Rename refactoring. See also IZ 144727, IZ 120145.
P2: There is never enough tests for watching performance regressions. More automated tests are needed for measuring e.g. total time of scanning (initial scan, up-to-date check after startup), use of threads (whitelist), touching files during startup (whitelist), memory usage, etc.
P2: We need all regularly running performance test to be stable and reproducible. Stability is needed to have complete historical data for all platforms (we had quite some data missing in the past); it is also necessary for the automatic regression detection to work. Reproducibility is needed for developers who need to fix performance regressions revealed by the tests.
P2: To catch performance regressions in the large number of tests we need an automatic detection of regressions (for time-based tests).
P2: Performance data is currently collected as part of all other test results and this process is maintained by person which is not part of performance team. One of the problem is that any kind of data processing outage can't be solved quickly. Moreover that database structure is not under our control and it doesn't fully support our needs. It seems to be more appropriate to move performance results database under our own full control.
P2: Performance dashboard needs to be improved to provide better regression analysis support.
P2: Use HgParallelProjectIntegration for early catching significant regressions and preventing their propagation into shared code base while _not_ preventing parallel teams in contributing and delivering their resulting products.
People facing performance issues often have difficulties to provide data to track the problem down. If the issue is hard to reproduce (which is a typical case) we ask people to give us thread dumps, heap dumps or histograms, or even create a profiling snapshot of the problematic operations. For many users this can be quite complicated and it significantly lowers the chance they will report performance problems and provide useful data. Why should the users learn how to use jmap, try to hit the right moment to generate thread dump (it's often difficult if the operation does not take enough time), or create multiple thread dumps or even learn how to setup profiler (if the problem is not apparent from one thread dump)?
P2: The IDE could provide more help here. E.g. it could be configured to generate histogram or heap dump on OutOfMemoryError (probably only for development builds), but it could also generate them on request directly. Especially useful would be if the IDE was able to create a profiling snapshot for specified time interval. E.g. the user would simply use a special shortcut to start and stop profiling the problematic operation, the IDE would use a simple "sampling" technique to collect data (basically equal to taking many thread dumps), saving it as a snapshot that can be opened directly in NetBeans profiler. This way we could get much better relevant data much easily than today. No more questions like "Can you generate more thread dumps?" Or: "Can you create a profiling snapshot for us? Please follow the simple 3-pages instructions below..."
P2: Get rid of deprecated APIs - lower the number of loaded classes/modules
- IZ 77030 - SystemOption
P2: Lazy load of editors
P2: Better mime resolvers
P2: Whitelist - make the difference between startup with project/without project smaller
- Use layer annotations to more effectively register objects, so they do not require eager loading
Actions loading speed
Currently the job of getting action names and shortcuts from KeymapManagers (options/keymap) is time consuming and must be done in EQ thread. QuickSearch feature is damaged badly by this, freezing for significant amount of time during first use, which makes for bad out of the box experience of whole QuickSearch feature.