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.
| Summary: | 25s - computing content of lookup when a lot of nodes is selected | ||
|---|---|---|---|
| Product: | platform | Reporter: | tomzi <tomzi> |
| Component: | Lookup | Assignee: | Jaroslav Tulach <jtulach> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | jmichelberger, jordao, mjr_1974, ovrabec, paolosca, powellblyth, yogi_varma |
| Priority: | P3 | Keywords: | PERFORMANCE |
| Version: | 7.4 | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | 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
Created attachment 139882 [details]
nps snapshot
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? Created attachment 143305 [details]
partial stacktrace
Created attachment 143306 [details]
yarda's patch
Jardo, your patch helped after all and made it much much faster. 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. *** Bug 240901 has been marked as a duplicate of this bug. *** Integrated into 'main-silver', will be available in build *201402170649* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/f143d26b5461 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #235748: Limit the recursion from updateCookiesFromLookup *** Bug 241548 has been marked as a duplicate of this bug. *** *** Bug 204645 has been marked as a duplicate of this bug. *** I am still seeing this issue in Release 8.0.1; Created attachment 150582 [details]
stack traces showing the issue in Netbeans 801 release, at multiple points
Issue still exists.
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: http://statistics.netbeans.org/exceptions/exception.do?id=748566 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 javax.management.openmbean.CompositeDataSupport 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.team.server.ui.common.OneProjectDashboard.create(OneProjectDashboard.java:132) at org.netbeans.modules.team.server.ui.common.DashboardSupport.<init>(DashboardSupport.java:96) at org.netbeans.modules.kenai.ui.api.KenaiServer.<init>(KenaiServer.java:103) at org.netbeans.modules.kenai.ui.api.KenaiServer.forKenai(KenaiServer.java:154) at org.netbeans.modules.kenai.ui.impl.TeamServerProviderImpl.getTeamServer(TeamServerProviderImpl.java:145) at org.netbeans.modules.team.server.api.TeamServerManager.getTeamServer(TeamServerManager.java:129) at org.netbeans.modules.team.server.Utilities.getLastTeamServer(Utilities.java:89) at org.netbeans.modules.team.server.TeamView.<init>(TeamView.java:100) at org.netbeans.modules.team.server.TeamView.getInstance(TeamView.java:140) at org.netbeans.modules.team.server.ui.common.OneProjectDashboard.getProjectPicker(OneProjectDashboard.java:1047) at org.netbeans.modules.team.server.ui.common.OneProjectDashboard.loadSelectedProject(OneProjectDashboard.java:609) at org.netbeans.modules.team.server.ui.common.OneProjectDashboard.handleLogin(OneProjectDashboard.java:310) at org.netbeans.modules.team.server.ui.common.OneProjectDashboard.initServer(OneProjectDashboard.java:267) at org.netbeans.modules.team.server.ui.common.OneProjectDashboard.<init>(OneProjectDashboard.java:196) at org.netbeans.modules.team.server.ui.common.OneProjectDashboard.create(OneProjectDashboard.java:132) Anyway your problem does not seem to have anything to do with lookup. Closing this bug and reporting as bug 249103 |