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.
Created attachment 106159 [details] NetBeans profiler snapshot I was working with ergonomics repository whole day. Then I decided to open one text file from inside fixes repository, it was: src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java.rej generated by failed attempt to apply a patch: $ patch -p1 </home/jarda/jarda.diff patching file src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java Hunk #1 FAILED at 102. Hunk #2 FAILED at 732. 2 out of 2 hunks FAILED -- saving rejects to file src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java.rej when I had this file in editor, I pressed Ctrl-Shift-1 and everything blocked for 42 seconds.
692 project.xml files loaded. Not sure what would cause this; looking at code, my only guess is that some SourceGroup.rootFolder was ${nb_all}. Anyway setKeys was not the problem, it was that BadgingNode was calling setProjectFiles synch in its ctor, and this can be an expensive call. core-main #610a300415cb (Was this really using 6.9? Or 7.0?)
Integrated into 'main-golden', will be available in build *201103100400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/610a300415cb User: Jesse Glick <jglick@netbeans.org> Log: #195659: setProjectFiles can be slow, so do not call it synch when making node.
No way to verify since there is only one report that I know of and no known way to reproduce. (Just opening the mentioned file does nothing special for me.) Also hard to say what user experience with patch would have been; there would still have been 42 sec of heavy disk activity, so IDE would probably have been only partially responsive. Fix seems generally useful and maybe medium-low risk.
(In reply to comment #3) > still have been 42 sec of heavy disk activity, so IDE would probably have been > only partially responsive. Fix seems generally useful and maybe medium-low > risk. Thanks for detailed explanation. In this case I would not integrate the fix into release70 and rather wait for 7.0.1 (so we will have more time to catch possible regression) - waiving for 7.0.