Please use the Apache issue tracking system for new NetBeans issues ( !!

Bug 235748

Summary: 25s - computing content of lookup when a lot of nodes is selected
Product: platform Reporter: tomzi <tomzi>
Component: LookupAssignee: Jaroslav Tulach <jtulach>
Status: RESOLVED FIXED QA Contact: issues <>
Priority: P3 CC: jmichelberger, jordao, mjr_1974, ovrabec, paolosca, powellblyth, yogi_varma
Version: 7.4Keywords: PERFORMANCE
Target Milestone: 8.0   
Hardware: All   
OS: All   
Whiteboard: EXCEPTIONS_REPORT perf-profileme
Issue Type: DEFECT Exception Report: 189156
Bug Depends on:    
Bug Blocks: 243724    
Attachments: nps snapshot
partial stacktrace
yarda's patch
stack traces showing the issue in Netbeans 801 release, at multiple points

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
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo