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.
6.8 final, windows vista, I did some code modifications outside the IDE. After that "scanning code..." is still happening, GUI is extremely slow, almost unusable. One core of my machine is 100% in use. Attaching stack trace and profiler snapshot.
Created attachment 92865 [details] profiler snapshot
Created attachment 92866 [details] stacktrace
If I read the profiler snapshot correctly the problem is in the logging to stdout/stderr by javac. A lot of the time is spent in flushing the output stream ... Please evaluate the TopLogging.LgStream.flush(). Thanks.
The question to ask is why there is so much logging from the compiler? Does it really print so much messages (and why), or does it just call flush without printing any messages? Simplest fix would be to provide no-op flush log impl. Dušan, can that be done?
If a DiagnosticListener is provided (which is the case of the java indexer), javac does not print any messages to stderr. So flush() is called without any logging from the compiler. Of course, providing no-op log impl is possible (see the attached patch), however, it only postpones the problem until some other code calls flush() on stderr IMHO.
Created attachment 93406 [details] patch
I've reported the slow flush as bug 179667 and I'll make it faster. Still, please apply your fix to JavaC. No flushing is always going to be faster than any optimized flush() implementation.
Patch applied http://hg.netbeans.org/jet-main/rev/c9c18b1d5226
Integrated into 'main-golden', will be available in build *201001240200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/c9c18b1d5226 User: Dusan Balek <dbalek@netbeans.org> Log: Issue #178981: Scanning is extremely slow - fixed.