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 6.9.1 (Build 201007282301) VM: Java HotSpot(TM) 64-Bit Server VM, 16.3-b01-279, Java(TM) SE Runtime Environment, 1.6.0_20-b02-279-9M3165 OS: Mac OS X Maximum slowness yet reported was 97212 ms, average is 50189
Created attachment 101808 [details] nps snapshot
attached profiler snapshot data doesn't show any slowness at all, probably a bug in slowness detector
GlobalActionContextImpl.blinkActionMapImpl() does a lot lookup() in EDT
Let's have a look at http://statistics.netbeans.org/exceptions/exception.do?id=619342 org.netbeans.modules.openide.windows.GlobalActionContextImpl.blickActionMapImpl() is called twice and takes 9s. Its time is equally split to SimpleProxyLookup$ProxyResult.updateLookup() 4 440 ms and $Proxy2.resultChanged() 4 426 ms which spends most of the time in org.netbeans.modules.editor.MainMenuAction.resultChanged() 4 426 ms (48,8%) Can I assign the bug to editor? Probably not, but CCing Míla. The SimpleProxyLookup$ProxyResult.updateLookup() is blocked, waiting in enterStorage() method. It looks like the lock is contended by AbstractStorage.cleanUpResult()1 101 ms which is said to be executed 4 times, but that is probably wrong number influenced by the fact the method is really short. It is interesting how many lookup results has to be generated, GC if simple call like public RefToResult cleanUpResult(Lookup.Template<?> templ) { final it = new AbstractLookup.ReferenceIterator(this.results); while (it.next()) { // empty } return this.results = it.first(); } can take 1s!? I'll add there some debugging information.
ergonomics#1573dbbbff01
I've just added more logging. We need to re-evaluate once we get new reports.
Btw I work on elimination of the MainMenuAction hopefully within 7.3 timeframe.
Integrated into 'main-golden', will be available in build *201210280001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/1573dbbbff01 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #190077: More logging to find out who is creating long lists of lookup results for the same type
*** Bug 211144 has been marked as a duplicate of this bug. ***
*** Bug 221944 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > *** Bug 221944 has been marked as a duplicate of this bug. *** New report from 7.3 Beta 2...
*** Bug 222228 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > *** Bug 222228 has been marked as a duplicate of this bug. *** Another report from 7.3 beta 2 - REOPENing - exception reporter keeps assigning new reports back to me since this bug is resolved...
*** Bug 222561 has been marked as a duplicate of this bug. ***
Waiting for report from newer version than 7.3beta2. It should contain more useful log messages.
*** Bug 221910 has been marked as a duplicate of this bug. ***
No report since 7.2beta2. I need logs from a newer version. As I am waiting for more than two weeks without a luck, I am closing the issue.
*** Bug 225863 has been marked as a duplicate of this bug. ***
In the last report there are several logs from NB 7.3 -> REOPENING
*** Bug 227430 has been marked as a duplicate of this bug. ***
I guess the right component is Lookup since it about cleaning up lookup results?
I will accept the bug into platform/lookup category once it is shown that it can be reproduced without using CND functionality. I have spend several days trying to locate the wrong usage of Lookup in CND qnavigator and I don't want to waste a minute more. Please reproduce without CND, in case this is impossible, search for enormous amount of create lookups in CND code and fix that.
*** This bug has been marked as a duplicate of bug 231767 ***