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 200909140908) VM: Java HotSpot(TM) Client VM, 14.1-b02, Java(TM) SE Runtime Environment, 1.6.0_15-b03 OS: Windows XP, 5.1, x86 User Comments: GUEST: i started the IDE GUEST: Starting NB. GUEST: Opened project Maximum slowness yet reported was 3969 ms, average is 3675
Created attachment 87667 [details] nps snapshot
This issue already has 6 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=157486
i need performance team's help with this one. tc group containing projects/files/services windows is being opened after projects have been opened. it is slow because topcomponents need to be deserialized and explorer manager(s) need to synchronized their root nodes
Build: NetBeans IDE Dev (Build 200909140908) VM: Java HotSpot(TM) Client VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01 OS: Windows XP, 5.1, x86 User Comments: I think waiting for this reporter dialog, but I cannot say whether it was really the cause Maximum slowness yet reported was 16172 ms, average is 5460
Created attachment 87697 [details] nps snapshot
This issue already has 7 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=157486
The last snapshot http://www.netbeans.org/nonav/issues/showattachment.cgi/87697/snapshot.nps shows that releaseJarFile() method is inefficient when classloading happens from multiple threads. In most occurences in the snapshot its wall clock time is at least twice as big as its execution time. It waits for other threads to release "sources" lock. Why "sources" lock is held? Looks like that new JarFile(...) can be quite expensive operation. And it is done while holding "sources" lock. Imho, the synchronization shall be rewritten to acquire the global lock just minimally, definitely not when doing I/O. Who wants to do it? Me, Nejdlák or Jesse?
If you believe you know in detail what's going on, feel free to take it because I have only some familiarity with this code.
I have never touched the code yet. I only read it with respect and humility. But Nejedlák told me that fixing this would be nice way to get back on speed after his finished affair with the Q.
*** Issue 172442 has been marked as a duplicate of this issue. ***
This issue already has 9 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=157486
Opening a jar no longer occurs under the lock. The fix is in the trunk only so far: http://hg.netbeans.org/main/rev/1fed72ac5bae
If you just committed it to main then it is going into 6.8 AFAIK - just not the beta. BTW changes like this would best be made in core-main.
Sure. And Yarda is very happy he didn't actually backported it to the beta clone ;-) Pushing to core-main would be fine, but in the light of all the hg down notices, I'm happy I have at least one usable local clone and team repos are to much of luxury for me then.