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 235748 - 25s - computing content of lookup when a lot of nodes is selected
Summary: 25s - computing content of lookup when a lot of nodes is selected
Alias: None
Product: platform
Classification: Unclassified
Component: Lookup (show other bugs)
Version: 7.4
Hardware: All All
: P3 normal (vote)
Assignee: Jaroslav Tulach
: 204645 240901 241548 (view as bug list)
Depends on:
Blocks: 243724
  Show dependency tree
Reported: 2013-09-10 13:56 UTC by tomzi
Modified: 2014-12-04 12:21 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 189156

nps snapshot (2.93 MB, application/nps)
2013-09-10 13:57 UTC, tomzi
partial stacktrace (31.79 KB, text/plain)
2013-12-18 14:16 UTC, Ondrej Vrabec
yarda's patch (1.21 KB, patch)
2013-12-18 14:37 UTC, Ondrej Vrabec
Details | Diff
stack traces showing the issue in Netbeans 801 release, at multiple points (254.71 KB, text/plain)
2014-11-19 23:32 UTC, sproger1

Note You need to log in before you can comment on or make changes to this bug.
Description tomzi 2013-09-10 13:56:44 UTC
Build: NetBeans IDE 7.4 Beta (Build 201307092200)
VM: Java HotSpot(TM) 64-Bit Server VM, 23.25-b01, Java(TM) SE Runtime Environment, 1.7.0_25-b15
OS: Linux

User Comments:
GUEST: Reverting modifications while scanning was taking place

tomzi: .

powellblyth: Accidentally Cmd+A on the file tree, Didn't know it would do that. Does it need to?

GUEST: selecting 200+ file in favorites window.

jmichelberger: Selecting multiple nodes in Files view.

Maximum slowness yet reported was 24439 ms, average is 7049
Comment 1 tomzi 2013-09-10 13:57:25 UTC
Created attachment 139882 [details]
nps snapshot
Comment 2 Ondrej Vrabec 2013-12-18 14:16:21 UTC
steps to reproduce:
1) open favorites and expand a folder with lots of files
2) wait until all nodes are loaded (all icons are correctly displayed)
3) Ctrl + A

From what we got while debugging:
- lookup is being built for all the nodes ProxyLookup$Result#1
- first node (when building its lookup) fires an event (for some reason its cookie set changes)
- the ProxyLookup$Result#1 catches the event and before passing it further it starts collecting all changes from all nodes again
- so it asks the second node which now fires another event => ProxyLookup$Result#1 again catches the event and recursively asks node after node again and again.

See the attached partial stacktrace, ProxyLookup$R is always the same instance, DataNode/DataObject instances are different in the stacktrace. Maybe ProxyLookup could be more clever and stop reacting on changes and recursively accessing all nodes when it's building?
Comment 3 Ondrej Vrabec 2013-12-18 14:16:26 UTC
Created attachment 143305 [details]
partial stacktrace
Comment 4 Ondrej Vrabec 2013-12-18 14:37:42 UTC
Created attachment 143306 [details]
yarda's patch
Comment 5 Ondrej Vrabec 2013-12-18 14:38:12 UTC
Jardo, your patch helped after all and made it much much faster.
Comment 6 Jaroslav Tulach 2014-02-14 11:18:02 UTC
ergonomics#f143d26b5461 seems speed the selection up significantly. Hopefully it won't cause many test regressions and I will be able to propagate it to 8.0.
Comment 7 Jaroslav Tulach 2014-02-14 11:21:45 UTC
*** Bug 240901 has been marked as a duplicate of this bug. ***
Comment 8 Quality Engineering 2014-02-17 09:03:31 UTC
Integrated into 'main-silver', will be available in build *201402170649* on (upload may still be in progress)

User: Jaroslav Tulach <>
Log: #235748: Limit the recursion from updateCookiesFromLookup
Comment 9 Jaroslav Tulach 2014-04-04 08:09:13 UTC
*** Bug 241548 has been marked as a duplicate of this bug. ***
Comment 10 Jaroslav Tulach 2014-04-04 08:50:51 UTC
*** Bug 204645 has been marked as a duplicate of this bug. ***
Comment 11 sproger1 2014-11-19 23:31:10 UTC
I am still seeing this issue in Release 8.0.1;
Comment 12 sproger1 2014-11-19 23:32:35 UTC
Created attachment 150582 [details]
stack traces showing the issue in Netbeans 801 release, at multiple points

Issue still exists.
Comment 13 Jaroslav Tulach 2014-12-04 12:21:12 UTC
What do you mean by "the issue"? Please be more specific. What happened to you and how that manifested? What you were doing?

I see only one report from 8.0.1 in the exception reporter:
but that report is about "OutOfMemoryError: Java heap space" which is something completely different than the original report in this issue!

The thread dump in the issue shows your IDE is parsing/checking the disk. That is however not a reason to throw OOME.

There is 7M of TreeMap.Entry instances occupying 412MB of memory. It could be related to which has 1.4M of instances. Possibly the slowness detector profiler has problems with deep stack traces that happen when StackOverFlowError is raised. And yes, there is one in messages.log:

	at org.netbeans.modules.kenai.ui.api.KenaiServer.<init>(
	at org.netbeans.modules.kenai.ui.api.KenaiServer.forKenai(
	at org.netbeans.modules.kenai.ui.impl.TeamServerProviderImpl.getTeamServer(

Anyway your problem does not seem to have anything to do with lookup. Closing this bug and reporting as bug 249103