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: | Allow lightweight and simple Children | ||
---|---|---|---|
Product: | platform | Reporter: | Jaroslav Tulach <jtulach> |
Component: | Nodes | Assignee: | t_h <t_h> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | issues, jglick, phrebejk, pkuzel |
Priority: | P3 | Keywords: | API, PERFORMANCE |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | TASK | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 19484, 35833, 38445 |
Description
Jaroslav Tulach
2003-04-08 12:24:03 UTC
openide has been branched as lightweight_32708 rooted at BLD200304080100 Maybe this could be merged into trunk as it makes the Children more readable and allows (after removing all the final keywords) completely different implementation. What do you think Hrebejk? IMHO if we use Looks over Nodes, we need to do some work like this to reduce memory overhead. If you look at heap size after creating a bunch of raw Look tree nodes vs. creating LookNode's, there's a huge difference - something like a factor of 10 more memory used when constructing Node's. Probably some of that is in Children.Keys - not sure, but it's not hard to find out with a profiler. Just run 'optit' target of performance/threaddemo/build.xml, use Look Nodes, expand some folder with 10k children, then look for any classes with >=10k instances. It should not be hard to unfinalize methods in Children and implement simple LookChildren (without change notification) directly and see the improvement. Instead of last comment to unfinalize some methods in getChildren (which would mix api and spi), the prefered way is to introduce new factory method: public static Children NodeOp.createFromList (List nodes); that would create the lightweight impl of children (without any Entry, Info, etc.) just delegating to the provided List. The creator of such list would then be responsible for firing correct events via Node.fire*Node* methods. Taking over the node bugs from phrebejk. Even better introduce interface Children.Interface (that will be implemented by all current Children subclasses). Required methods: getNodes(), getNodesCount(), addChildrenListener() <new one> *** Issue 38445 has been marked as a duplicate of this issue. *** Duplicatte added value excerpt: I though about implemeting my own children but I have not found any way how to notify about change. There is probaly some package private contract. Well, getNodes() would not allow to write scalable code either. So it's better to copy DOM's NodeList interface (or CharSequence) and have following Children.Interface methods: int getNodesCount(); Node nodeAt(int index); It allows a view (consumer) to ask only for nodes it really needs to visualize. No big Node[] array must be held in memory. Events can be addressed by testing for being an instance of Children.EventSource class (inspired by DOM too): addChildenListener(l) removeChildrenListener(l) where the ChildrenListener interface is like: void chidrenEvent(e) and the ChildrenEvent is (inspired by BeanContextMembershipEvent): // is there a change in given range boolean changeInRange(int lowInclus, int hiExclus); // new children size (to detect removal/insert) int sizeAfterChange(); // no need one can ask source directly // and optional method that can be added later on: // changed indexes (insert at 0 returns very long array) int[] indexes(); Just my 2 bytes. I think the issue_35833 branch already has a very similar API. Reassigning to new module owner Tomas Holy. LookChildren are gone. Btw. another approach for something lightweight was made as part of issue 46900 |