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.

Bug 190077 - Long delays because of cleaning up lookup results
Summary: Long delays because of cleaning up lookup results
Status: RESOLVED DUPLICATE of bug 231767
Alias: None
Product: cnd
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 6.x
Hardware: All All
: P3 normal (vote)
Assignee: Andrew Krasny
URL:
Keywords: PERFORMANCE
: 211144 221910 221944 222228 222561 225863 227430 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-09-01 14:41 UTC by Exceptions Reporter
Modified: 2013-08-02 10:29 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 168055


Attachments
nps snapshot (8.97 KB, application/nps)
2010-09-01 14:42 UTC, Exceptions Reporter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Exceptions Reporter 2010-09-01 14:41:56 UTC
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
Comment 1 Exceptions Reporter 2010-09-01 14:42:00 UTC
Created attachment 101808 [details]
nps snapshot
Comment 2 Stanislav Aubrecht 2010-10-07 09:56:45 UTC
attached profiler snapshot data doesn't show any slowness at all, probably a bug in slowness detector
Comment 3 Stanislav Aubrecht 2012-10-02 09:32:05 UTC
GlobalActionContextImpl.blinkActionMapImpl() does a lot lookup() in EDT
Comment 4 Jaroslav Tulach 2012-10-24 08:29:11 UTC
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.
Comment 5 Jaroslav Tulach 2012-10-24 08:58:59 UTC
ergonomics#1573dbbbff01
Comment 6 Jaroslav Tulach 2012-10-24 08:59:40 UTC
I've just added more logging. We need to re-evaluate once we get new reports.
Comment 7 Miloslav Metelka 2012-10-25 11:40:13 UTC
Btw I work on elimination of the MainMenuAction hopefully within 7.3 timeframe.
Comment 8 Quality Engineering 2012-10-28 01:49:07 UTC
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
Comment 9 Jaroslav Tulach 2012-11-05 14:18:51 UTC
*** Bug 211144 has been marked as a duplicate of this bug. ***
Comment 10 Jan Peska 2012-11-13 09:47:28 UTC
*** Bug 221944 has been marked as a duplicate of this bug. ***
Comment 11 Jan Peska 2012-11-13 09:48:43 UTC
(In reply to comment #10)
> *** Bug 221944 has been marked as a duplicate of this bug. ***

New report from 7.3 Beta 2...
Comment 12 Jan Peska 2012-11-21 10:26:55 UTC
*** Bug 222228 has been marked as a duplicate of this bug. ***
Comment 13 Jan Peska 2012-11-21 10:29:41 UTC
(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...
Comment 14 Jan Peska 2012-11-22 08:37:37 UTC
*** Bug 222561 has been marked as a duplicate of this bug. ***
Comment 15 Jaroslav Tulach 2012-11-29 12:16:51 UTC
Waiting for report from newer version than 7.3beta2. It should contain more useful log messages.
Comment 16 Jaroslav Tulach 2012-11-30 16:06:30 UTC
*** Bug 221910 has been marked as a duplicate of this bug. ***
Comment 17 Jaroslav Tulach 2012-12-17 13:08:33 UTC
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.
Comment 18 Jan Peska 2013-05-15 07:53:04 UTC
*** Bug 225863 has been marked as a duplicate of this bug. ***
Comment 19 Jan Peska 2013-05-15 07:54:50 UTC
In the last report there are several logs from NB 7.3 -> REOPENING
Comment 20 Jan Peska 2013-07-11 08:36:16 UTC
*** Bug 227430 has been marked as a duplicate of this bug. ***
Comment 21 Jan Peska 2013-07-11 08:42:45 UTC
I guess the right component is Lookup since it about cleaning up lookup results?
Comment 22 Jaroslav Tulach 2013-07-30 11:54:50 UTC
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.
Comment 23 Vladimir Voskresensky 2013-08-02 10:28:53 UTC

*** This bug has been marked as a duplicate of bug 231767 ***