This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Hy, I've noticed that the Navigator window has a noticeable delay while showing the members view. Not only that, but the delay seems to be kinda constant in time, no matter what (or if) changes happened. My example is just switching between an editor window for Java to the Projects view (but not selecting some other file). What this does is basically toggle the navigator window between the Java file's hierarchy to an empty window (since "projects" have no navigation). The annoying part is that after each toggle, the time is constant to show the Java file view, although nothing really changed. There is also a big CPU spike after each focus change, which makes me believe that probably the file is re-scanned or recompiled. It would be really nice if the navigator would be smart enough to keep a cache and/or only re-scan changed files. The 2-3 seconds delay for one file on a dual core machine shouldn't happen.
>What this does is basically toggle the navigator window between the Java file's hierarchy to an empty window (since >"projects" have no navigation). The navigator is driven by the active (selected) node. The project node is not navigable, so there is nothing to show. >The annoying part is that after each toggle, the time is constant to show the Java file view, although nothing really >changed. There is also a big CPU spike after each focus change, which makes me believe that probably the file is >re-scanned or recompiled. Yes, the file is rescanned every time you return back into it. The reason is that your changes in other file or project setting may significantly change the file semantics (some types may become [in]valid). The navigator is a parser result task which is triggered automatically after parser completed the parse. >It would be really nice if the navigator would be smart enough to keep a cache and/or only re-scan changed files. The >2-3 seconds delay for one file on a dual core machine shouldn't happen. Yes, it's possible (but not easy) to keep a cache for single file, when you return to the same java file it will be faster.
Well, this kinda makes sense from an implementation standpoint. But if I *didn't* make any project changes so that the semantics might change and I *didn't* make any file changes, why does the IDE feel the need to rescan the file and spend resources just to show me the exact same thing ? This isn't just inefficient as it breaks my flow as a programmer (having to noticeably wait for the navigator to show up info), but it's presumably also inefficient as it hits the disk every time and uses CPU (and battery) to do the scanning. I presume it's not a very high priority bug but it would be nice to optimize this.
Unfortunately tracking that nothing has changed is nearly impossible. Any change of any file (including metadata files) in project and dependent project causes a change. For example external SVN update. Anyway the navigator can be optimized as I've described above.
The primary optimization point for the navigator is distinguishing between members in the current class and inherited members. This is especially relevant when the "Show Inherited Members" button is not checked. In this situation the navigator can be completely displayed from the parse tree from a single file, which should take less than a second even on *very* large files, and doesn't rely on the project scanner to have completed the initial parse of a project. In addition, due to the particularly visible nature of the navigator pane's content, the following measures should be taken to ensure usability when "Show inherited members" is checked: * Members from the current file should be displayed immediately with some sort of an indicator that an asynchronous update of inherited members is in progress. * The background parser should prioritize the parsing of source files which form the full set of base classes for types in the current file. For as much as I loathe Java's restriction that a class be named the same as the file it's in, let us at least get something out of it. :) * The navigator should present the complete set of information immediately upon completion of parsing of base classes of types in the current file. It should not be delayed by continued background parsing of the rest of the project. When these considerations are combined with some corrections to the parse task scheduler latencies and priorities I'm working on, the navigator should prove responsive on a sub-250ms level even with projects the size of NetBeans or the JRE source.
Several improvements were done in NB 7.2: 1st) The navigator is not blocked by scan 2nd) The navigator priority was increased 3rd) The caching. When you reselect a file for which the navigator was already calculated and the Source reference already exists no parsing is needed the parse result is taken from the source and navigator just travels the tree and creates UI nodes.