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 48685 - Excessive recreation of node children
Summary: Excessive recreation of node children
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Infrastructure (show other bugs)
Version: 4.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: Jesse Glick
Depends on:
Blocks: 41535
  Show dependency tree
Reported: 2004-09-08 14:53 UTC by Jesse Glick
Modified: 2006-03-24 10:09 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Some stack traces (246.22 KB, text/plain)
2004-09-08 14:53 UTC, Jesse Glick

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2004-09-08 14:53:08 UTC
See the attached stack traces. I just put
Thread.dumpStack into Children.Keys.applyKeys.
Then I ran the IDE with setup as in issue #48630,
expanded some project logical nodes to the file
level, and began moving up and down.

Stack traces are only from the period *after* I
had expanded everything I was going to expand. So
you can see that even for already-expanded node
trees, Children.Keys.getArray is often calling
addNotify. This must mean that the 'array'
reference has been cleared. Which is not
surprising, since it is a weak reference! Meaning
it will be cleared constantly.

Surely at least *currently expanded* children
could hold their nodes strongly, or softly, or
Comment 1 Jesse Glick 2004-09-08 14:53:45 UTC
Created attachment 17485 [details]
Some stack traces
Comment 2 Petr Hrebejk 2004-09-08 17:47:15 UTC
CCing Jarda as it is probably hi weak reference in case you are
talking about org.openide.nodes.Children.array.
Comment 3 Jesse Glick 2004-09-08 18:07:40 UTC
I think it is Reference Children.array I am referring to. It is always
set to a WeakReference.
Comment 4 Petr Hrebejk 2004-09-09 09:58:08 UTC
It is not true that the opened nodes are garbage collected. They are not. 
The problem is in the project nodes which are closed. If you go up and
down through the explorer the SubnodesSearchInfo.canSearch() asks for
all nodes of given node. (Notice that all the stack traces have the
SSI in them) The PackageViewChildren are created and then obviously
GCed because the node is collapsed.
Wondering if this behavior of the SSI is realy necessary.
Comment 5 _ pkuzel 2004-09-09 15:43:08 UTC
My suggestion is that LogicalView.RootNode lookup() should provide
optimalized SearchInfo (see API). Possibly always
returning true.
Comment 6 Jesse Glick 2004-09-09 16:49:17 UTC
My, you're right. The SubnodesSearchInfo is just ridiculous. I can't
imagine any circumstance where you would want the default
implementation of canSearch; it means a recursive traversal of all
subnodes, doesn't it?? Or at least expanding down to folders, which is
bad enough. I will try hardcoding canSearch to true and see if that
helps things.
Comment 7 Jesse Glick 2004-09-09 21:53:01 UTC
Thanks for the tip. Dramatically speeds up navigation.

committed   * Up-To-Date  1.14       
committed   * Up-To-Date  1.42       
committed   * Up-To-Date  1.30       
Comment 8 Petr Nejedly 2004-09-09 22:09:46 UTC
> The SubnodesSearchInfo is just ridiculous.
Isn't the API bad then?
Comment 9 Antonin Nebuzelsky 2004-09-10 13:29:01 UTC
Fix of this issue significantly improves the problem described in
issue 48630 which has been identified as beta 2 stopper.

Thus marking this one as a candidate for merge to release40_beta2 branch.
Comment 10 Jesse Glick 2004-09-10 17:00:30 UTC
Re. whether the SubnodesSearchInfo is a bad API - well its
implementation is correct. It's just slow. I imagine there could be
some circumstance where you had some node which sometimes could be
searched and sometimes couldn't be searched. That just isn't the case
for the projects use case; of course you can search the project, there
is no reason to do any further checks. I suppose you could disable
Find in case the project was empty, or something like this, but that
is just being pedantic; it provides no real value to the user, it just
makes the IDE slower.

Will try to merge to the beta2 branch.
Comment 11 Jesse Glick 2004-09-10 18:21:01 UTC
Merged to release40_beta2:

Checking in
new revision:; previous revision: 1.12
Checking in
new revision:; previous revision: 1.39
Checking in
new revision:; previous revision: 1.29
Comment 12 Jaromir Uhrik 2005-07-14 16:20:18 UTC