JavaPerfImprovements70

NB 7.0 performance improvements in Java infrastructure

Contents


1. 'Find Usages' and related refactorings

Discussion

  • Performance of Find Usages perceived as problem. People complain a lot. Some searches may take so long it looks like they do not finish.
  • Maybe 40% of time takes collecting the classpath (processing queries).
  • Want to speed up significantly Find Usages and most common refactorings that use it (mostly Rename refactoring).
  • There is a chance for significant improvement.

Conclusion

  • Implement and use full index (all identifiers). Expected slowdown of initial scanning should be less than 10% (acceptable). Owner: Java team
  • Optimize the sequence of querying the class index (not to jump around between source roots, topological sort to reduce number of necessary queires). Owner: Java team + performance team
  • Find how to measure improvements - a benchmark test trying to find usages of all identifiers in JEdit? Owner: Performance team - Pavel

2. 'Go to File' performance

Discussion

  • Makes sense to speedup by creating a file index.
  • Indexing only source roots, searching in the rest sequentially (directly on disk).
  • Parsing API could take care of the index - if it knows about all source roots (i.e. mainly GSF must be integrated).

Conclusion

  • Extend the infrastructure (parsing API) to build all files index (for source roots). Owner: Java team - Tomas Zezula
  • Modify Go to File dialog to use the file index and search in the remaining files. Owner: Java team, performance team might help (should be max 1 week of work in total)

3. Parsing API

Discussion

  • Need to include GSF (probably with lang. embedding).
  • Also Task list - should be able to rewrite the providers to use parsing API to be notified when to scan what.
  • Parsing API (indexing API) would also take care of checking files for updates (remembering time stamps, etc).
  • Given the dependencies, parsing API needs to be ready relatively soon in the release cycle.

Requirements

  • Make sure only one thread does the file scanning (reduce duplicated scanning threads).
  • Avoid the periodical 2s awakening of the parser thread.
  • All files should be traversed only once.
  • Reduce duplicated classes (that do the file scanning and updating etc, each on their own).

4. Scanning

Discussion

  • Idea of full IDE usability during scanning and using old data is nice, but hardly doable, risky, no time for that.
  • We could try to make at least Go to Type/File really working during up-to-date check by enabling to use index API during the scan.
  • We could try to give users a prototype of "Eclipse" model - no checking on external changes, see what they'll tell us.
  • Another alternative is some blocking UI after startup - until scanning is over.
  • There is a chance to speed up compilation for misplaced classes (more top level classes in one file, not matching package declaration). In some cases can be 2 times faster (one compilation reduced).
  • Repository updater can be stopped during VCS update operation. All java features will work, just the updater will not scan until the entire VCS operation is finished. (It is not likely this could work per source root during update.) Need to solve dependencies between java and vcs.
  • No special actions planned to diagnose users' problems with frequent/long scanning.

Conclusion

  • Create a module for AU which would disable auto-refresh (and up-to-date check after startup), with explicit refresh action let people play with it. Owner: Java team to provide basic patch, Jarda to create the module
  • Prototype some kind of blocking UI after startup. Owner: Jarda + Jano Rojcek
  • Optimize compilation for misplaced classes. Owner: Java team - Jan Lahoda
  • Make VCS updates not cause multiple refreshes by stopping the repository updater Owner: Jarda with help of java team
  • Queries to index API possible during parsing running (to make Go to Type responsive during scanning). Owner: Java team
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo