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.
I've got a problem using some 10.000 classes in a project. I'm using them just as reference, mainly to look at the class hierarchy in the navigator. The problem: Overriding methods in the editor is working quickly, but waiting for the navigator often takes 10-15 minutes, sometimes even more, so the navigator is my development bottleneck. I've tried to find out, why, and it seems, that navigator doesn't make use of the indexed files in var/cache. I've tried to get further information on the mailing lists, but failed.
Which filters do you have enabled in navigator? Can you capture and attach here several threaddumps, when you're waiting for navigator update? Thanks
Usually, I set all the filters to active state, so I can see every class member, if implemented locally or in a superclass.The classes are from an application, which I've to adopt for customer needs. Thus, navigator is an important tool for me to find methods and fields quickly, and of course I like the javadoc tooltips. Probably, delay would be less exhaustive, if I'd not have to use the sources over network, but otherwise it's a modern (core 2 duo) machine, so NB should run quickly. As editor is much faster than navigator, I guess, that either var/cache isn't used, or all the javadoc is scanned from all the sources at the time navigator is opened. If the latter is true, it should be fixed by an in-memory cache, being filled lazily when the javadoc comments are used as tooltips (probably even remaining empty, if the javadoc is never used).
Thanks for additional info, we'll investigate it
The pain has even been increased: After download of latest daily build, the editor stops until the navigator has been initialized! Thus, I've to wait after switching from one file to the other - probably I'll better switch back to editor usage :-( :-( :-(
Probably related: After using the "slow NB" for some time, I've noticed that scanning doesn't ever stop, if any NB module project (probably only those hosted in suites) is open. I've been used to have a module project open, so this might be the original problem. It seems as if module projects are conflicting with "regular" java projects ...
Seems to be a circularity problem: Say, mod1 is loaded from suite containing mod1-mod3. Thus, mod1 has to be indexed in context of suite, so suite is searched, while already scanning mod1. suite starts scanning of dependents mod1-mod3. While scanning mod1-mod3, they lookup their suite, starting additional scans. This conforms to what I see: Scanning is always restarting. The correct way would be: If a module is contained in a suite, it should be started *only* by suite indexing, not by itself: 1. Lookup all projects to be indexed 2. Collect all those projects, as long as they are not dependends of a suite, otherwise collect the suite (not needed to be open) 3. Index them.
Hm, I've noticed non-stopping scanning also in a single-module project (non-IDE), while it seems the problem does not exist in IDE-modules. Also, there's now "cluster.path" needed in single-module projects, while it has been needed only for suite projects before. Probably scanning is also indexing the referenced clusters? Then, probably, the index files should be delivered along with NetBeans ...
*** This issue has been marked as a duplicate of 153883 ***