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.
[ BUILD # : RC1 ] [ JDK VERSION : 1.6.* ] As scanning for Navigator and Tasks view sometimes takes too much time, please first process collapsing code folds for seamless edit performance.
Ulf, you mentioned in one of your mails to netcat that this issue is obsolete in the dev builds (trunk/6.8.). Can we close this report then?
I guess, the task "First process collapsing code folds" is not done yet, but for now it seems to be not necessary. You can close it. If collapsing becomes slow again, I would reopen it.
Unhappily I must reopen this issue. When making changes to "important" classes like String, I have to wait 1..15 min. until editing in comfortable collapsed state is possible. After initial start and first project scan (up to 15 min.) collapsed view is real fast, but after some time of working it becomes slower and slower.
Could you be more specific please? What exactly you do? Does closing the Navigator (or tasklist) help? Can you generate a log with -J-Dorg.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.level=FINE? Also remember that when changing anything in a class that is publicly accessible from the outside (eg. a public method signature) the IDE is likely to rescan classes that depend on (use) the modified class. In case of java.lang.String this can be a lot of classes to compile.
> Could you be more specific please? What exactly you do? I change some or more characters in a java source file, save it, and new scan starts in background. When I open another java source file, I have to wait very long time to have the javadoc collapsed. > Does closing the Navigator (or tasklist) help? > Can you generate a log with -J-Dorg.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.level=FINE? I will try this. > Also remember that when changing anything in a class that is publicly accessible from the outside (eg. a public method > signature) the IDE is likely to rescan classes that depend on (use) the modified class. In case of java.lang.String > this can be a lot of classes to compile. For sure, this is the reason for this. ... but this issue is not about enhancing the scan speed, it's just about collapsing the default code folds first on opening an editor tab, instead of waiting for successful navigator and other scans, so user can instantly start scrolling and typing.
"it's just about collapsing the default code folds first" - Ok, I'll see what we can do about this.
Related to / depends on ? bug 177261.
Fixed jet-main 41985eb45913