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.
This bug was originally marked as duplicate of bug 220173, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related. Build: NetBeans IDE 7.3 Beta 2 (Build 201211062253) VM: Java HotSpot(TM) Client VM, 23.5-b02, Java(TM) SE Runtime Environment, 1.7.0_09-b05 OS: Windows 7 Maximum slowness yet reported was 41261 ms, average is 41261
Created attachment 128169 [details] nps snapshot
One call to org.openide.util.lookup.ProxyLookup$1Notify.run() 99.949615 41,098 ms (99.9%) 38,133 ms 1 leads to 1000 calls to org.netbeans.modules.project.ui.OpenProjectList$LoadOpenProjects.resultChanged() 44.261333 18,199 ms (44.3%) 18,199 ms 1042 (looks like there is 1000 of results created in OpenProjectList singleton!?) and org.openide.awt.ContextManager.isEnabled() 50.359325 20,707 ms (50.4%) 17,792 ms 1054 where I am not sure on which action the manager operates. The later problem is duplicate of bug 220173 - I've added logging (please run with -J-Dorg.openide.awt.GeneralAction.level=FINE to capture it). Leaving up to Miloš to look at the OpenProjectList$LoadOpenProjects case.
(In reply to comment #2) > One call to > > org.openide.util.lookup.ProxyLookup$1Notify.run() 99.949615 41,098 ms > (99.9%) 38,133 ms 1 > > leads to 1000 calls to > > org.netbeans.modules.project.ui.OpenProjectList$LoadOpenProjects.resultChanged() > 44.261333 18,199 ms (44.3%) 18,199 ms 1042 > > (looks like there is 1000 of results created in OpenProjectList singleton!?) I don't see how that could be possible. OpenProjectList is a singleton, LoadOpenProjects is created only in it's constructor and contains just one Utilities.actionsGlobalContext().lookupResult(FileObject.class); result that uses a weak listener to listen on changes.
Created attachment 129409 [details] nps snapshot
after looking at 4 different snapshots, the slowness in OpenProjectList seems to be attributed to starting RequestProcessor mainly? That's what we only do in the resultChanged method. So the only explanating appears to be that the RP is getting populated fast, the RP queue grows and is being processed slower than it's growing. This changeset protects against such flooding https://hg.netbeans.org/core-main/rev/39d2f86fc736 reassigning back to actions.
The fix 39d2f86fc736 does not address anything. RP.post is implemented through RP.schedule and it was the RP.schedule that was slowing you down according to the snapshot from comment 1. You can improve the situation a bit by using FastItem and not SlowItem (see constructors for RP). The real fix would however investigate why somebody attached 1052 LoadOpenProjects listeners to Utilities.actionsGlobalContext lookup. I've tried that in ed4d6c4b0fcc for the action part of the issue.
(In reply to comment #6) > The fix 39d2f86fc736 does not address anything. RP.post is implemented through > RP.schedule and it was the RP.schedule that was slowing you down according to > the snapshot from comment 1. > > You can improve the situation a bit by using FastItem and not SlowItem (see > constructors for RP). Then I don't follow why the problem is assigned to me. > > The real fix would however investigate why somebody attached 1052 > LoadOpenProjects listeners to Utilities.actionsGlobalContext lookup. I've tried > that in ed4d6c4b0fcc for the action part of the issue. 1052 listeners is one explanation, another one is that actionsGlobalContext was changing fast (IMHO better one)
reassigning to requestprocessor owner. I don't see anything wrong in the Openprojects codebase, performed the analysis that I was asked for and don't see anything to fix in project codebase, if the RP.schedule() method needs improving then it's outside of my competency. As is frequently changing global context.
Not related to extexecution at all - it seems to be RP. Reassigning back.