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: NetBeans IDE Dev (Build nbms-and-javadoc-4251-on-091107) VM: Java HotSpot(TM) Client VM, 11.2-b01, Java(TM) SE Runtime Environment, 1.6.0_12-b04 OS: Windows Vista, 6.0, x86 User Comments: GUEST: Opening projects during startup takes forever. GUEST: SVN update krezelokdaniel: I put the curosor in Search text field and choose item from proposal. GUEST: Types ctrl-shift-I onmomo: Pressed Ctrl+ I in the quicksearch box Maximum slowness yet reported was 14923 ms, average is 7569
Created attachment 90892 [details] nps snapshot
This issue already has 11 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=158445
Time spent in class loading. Cannot fix in filesystems.
This issue already has 12 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=158445
http://statistics.netbeans.org/exceptions/exception.do?id=299333 seems to indicate problem in quicksearch. It shall probably query the mimelookup in other than AWT thread. http://statistics.netbeans.org/exceptions/exception.do?id=299326 is similar. So is http://statistics.netbeans.org/exceptions/exception.do?id=298858 Reassigning to quicksearch.
Well, I knew that this slowness report will come, I just wandered why it took so long? I thought that nobody is using QuickSearch and I'm happy that this is not the case. To the problem: Actions must be loaded in AWT thread, they fail and throw assertions otherwise. As a result, first usage of Quick Search blocks EQ thread for several seconds. Some API to retrieve action names outside EQ is needed, until that this issue is not fixable. Problem is already tracked in 137829. *** This bug has been marked as a duplicate of bug 137829 ***
I am glad you are glad. 1. Actions instances in NetBeans can be created outside of AWT thread. MenuBar and Toolbar supports do it, so at least for those actions it is guaranteed to work. Btw. why it should not? Action is just an interface, its instantiation does not need to call the UIManager, L&F, or obtain AWT tree lock. 2. Just calls to action.getValue and other methods need to happen on AWT thread. 3. Even if you wanted to instantiate actions in AWT, you could still split this task into many small and fast runnables interlaced with showing the progress or letting user to cancel the operation. Of course the other solution is to convert more actions into declarative ones. If you can identify the slowest, please reassign the bug to appropriate module authors. Btw. the exception reporter may attempt to reopen or increase priority of bugs that continue appearing automatically.