PostNB69PerfGoals

This page collects specific performance goals for NB 6.10 release. It's based on PostNB69PerfTopics, please read it for more background.

The main goal is to significantly reduce scanning related problems that bother our users. This includes improving performance of the scanning itself, fixing bugs in unnecessary scanning, but also improving how the IDE works for the user, making features available and responsive no matter what the IDE is doing on background (how much or how long it is "scanning"). The scanning should be more a truly background task that does not block or influence anything.

This general goal breaks down to many specific tasks, though not everything can be listed here, also because not everything can be done in one release. But we should achieve some critical mass that makes a visible difference for most users that experience "scanning" problems today.

The goals below are approximately sorted by importance.

Contents

Features available even during scanning

Scanning should not block features that does not modify code. The features should normally work against the last available data from indexes. Up-to-date check or any other scanning should run independently, just updating (meta)data when done. We can consider several "levels" of features by importance or difficulty to make them scanning-independent:

  1. Navigation, i.e. Go to File/Type/Symbol, Navigator view, Ctrl+click in editor (Go to Declaration). Navigation should always work as long as the IDE is able to open a file in editor.
  2. Code completion.
  3. Finding usages and other features not modifying code (running project (if not in CoS mode), debugging, running test, etc).

Notes:

  • For #3 we need to specify the exact features and situations where it is reasonable to work against the "old data" and not wait for up-to-date results provided by scanning.
  • See also bug 182653.

Feature responsiveness not affected by scanning

Operations invoked by user should be fast and responsive no matter if there is some background operation run by the IDE (typically I/O intensive, like parsing/indexing). This is important addition to the "availability" goal: the features need not only be available during scanning, but also perform well.

Possible test case: Start IDE with a project opened, no file opened in editor. Open a file via Go to Type (Ctrl+O, Ctrl+V the name of file, Enter). Measure the overall time from Ctrl+O to showing the file in editor. Compare with situation when another project is being opened so there's scanning running while opening the file.

Eliminate unwanted scanning

Make the IDE do only necessary amount of scanning, and start only in situations when it is really needed.

Note: This is hard to define or quantify. It's an ongoing effort to fix bugs that cause the "scanning too much/too often" complaint. Maybe also some improvement in diagnostics (logging) would be useful.

IDE responsive after switch from another application

When switched back to IDE from an external application, the responsiveness and performance of features should not be negatively affected. The user should not be bothered by the fact the IDE needs to do some background processing (e.g. to detect external changes). It's especially important in scenarios when this happens very often (e.g. debugging, PHP development, etc).

Note: Native file listeners would solve the problem of too visible/intrusive external check, also provide results (found changes) much faster, plus give correct results in all situations (unlike the current check on window focus gain). To just make the IDE responsive after switch from another app, it may be solvable even without native file listeners.

Fast navigation

Make Go to File/Type/Symbol always fast and responsive (as you type). We've collected a lot of slowness reports in bug 177274. There are also known limitations in the Go to Type implementation (e.g. how it reduces the result list with additionally typed chars).

Note: Fast "Go to..." is mentioned separately as there are other specific problems and possible solutions, not only those caused by concurrent scanning.

Fast switching of files in Navigator

When switching between files in editor, Navigator view should update immediately (in less than 0.5s if the file has already been opened in Navigator). It's already pretty fast when selecting in Projects explorer.

Scale with HW (make use of resources)

Scaling with memory means that with more memory the user should perceive better performance of the IDE. Memory should be used for more caching to overcome the slow I/O which is a known bottleneck. If there's enough memory, use it automatically for data that is often read from disk or re-compiled (e.g. java indexes, parsed data for Navigator, etc).

Permanent self-profiling

Allow self-profiling run all the time, keeping data for last 5 minutes, thus making it easier to provide snapshots for performance problems (even retrospectively). Enable submitting snapshots created this way from the IDE, possibly associated with UI gestures log. Improve profiler to

Debugger: Fast stepping

Improve debugger so every step takes less than 100ms. Invoking a next step should not be blocked by various updates and computation done after each step.

Other

Remove finalizers from classes like ProxyLookup.R, FilterNode, ...

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