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.
org.openide.util.lookup.SimpleLookup is a good start, but it is still probably heavier than it needs to be. It keeps a collection of items (an array would be lighter), and rather than just storing the instances directly, it uses InstanceContent.SimpleItem wrappers for some reason, which also add an int field from AbstractLookup.Pair. IMHO if you call Lookups.fixed(Object[] objs), it should return an object with only one field - objs. All lookup methods can just scan that array and do what they need. Similarly, Lookups.singleton produces too large a Lookup object to hold just one instance. Should be a special class dedicated to this use, perhaps, or making a singleton array would be OK. We are also missing some simple factory for making a *small* lookup that would serve as a decent replacement for CookieSet, i.e. permit runtime modifications (unlike Lookups.fixed). Suggest: public static final class MutableSimpleLookup extends Lookup { public MutableSimpleLookup(Object[] initial, Object key); public void add(Object nue, Object key); public void add(Object[] nue, Object key); public void remove(Object old, Object key); public void remove(Object[] old, Object key); public void remove(Class pattern, Object key); public void set(Object[] nue, Object key); } Optionally have similar methods taking convertors. The key may be any object, even null, and all mutator methods must be passed the same (==) object (or they throw a SecurityException). Permitting any key avoids the overhead introduced by the InstanceContent pattern, which requires a separate content object in all cases. This mutable lookup should have no fields besides a list of objects (array or ArrayList), the key, and a weak set (null whenever possible) of Result's that might need changes fired. To save space if convertors are supported, the pair of convertor and converted object should be kept in the same slot as a plain instance - this is safe polymorphism since the pair would be a private class. Should be rather less memory-intensive (and probably less CPU-intensive too) than AbstractLookup for lookups with small instance counts.
Improving implementation of fixed and singleton is desirable task and I would like to suggest to also improve implementation of AbstractLookup + its Content. The current implementation of AbstractLookup is obviously too heavyweight for tiny content, but the current InheritanceTree field there can be easily replaced by an array of objects, if the number of objects < say 20. Similarly, the hashmap of all results could be kept in an array if there is not a lot of results. The AbstractLookup.Content was supposed to be lightweight class - the earlyPairs support is not very useful extension, that is moreover poorly written, as the ArrayList is created regardless its need. This shall be deleted and throw (or at least log) an exception. In short, I would rather invest in easy runtime tuning: improve performance and dynamically react to system behaviour. That gives us the best improvements with the least effort (as modules do not need to change anything).
Perhaps AL + IC can be improved to be much lighter-weight for small data sizes, I don't know. As I mentioned, there is a (modest) penalty for forcing you to keep the AL and IC as separate objects - proposed MutableSimpleLookup would let you reuse some private object you already had available, which could be an advantage when you are dealing with small common objects, e.g. data objects needing to add/remove SaveCookie. But perhaps not significant compared to other sources of overhead.
This sounds like useful thing. Do you expect me to implement it for next version?
I would say it should be implemented as needed e.g. to support efficient impls of Looks.
OK. Marking as future. Can be changed to 4.0 if needed. PetrH, speak up if you need this.
I have create an experimental branch in module openide for packages src/org/openide/util and test/unit/src/org/openide/util/lookup to try this ide. Use: cvs co -r two_storages_32203 -f openide
The two_storages_32203 is ready to be integrated. I'd like to do it next week.
cvs -q ci -m "#32203: Communication between AbstractLookup and its storage abstracted - now done via Storage interface. There are two (+1) implementations - the original InheritanceTree and new ArrayStorage. ArrayStorage just keeps the list of Pairs in an array, occupies less memory and does most operations by computational power. Is optimized for Results with one listener. InheritanceTree is suitable for larger data with a lot of results and continues to work in the same way. As a first result of this change the size of LookNode after getLookup() in LookNodeTest was reduced by 53%." Checking in looks/test/unit/src/org/netbeans/api/nodes2looks/LookNodeTest.java; /cvs/openide/looks/test/unit/src/org/netbeans/api/nodes2looks/LookNodeTest.java,v <-- LookNodeTest.java new revision: 1.7; previous revision: 1.6 done Processing log script arguments... More commits to come... Checking in src/org/openide/util/lookup/AbstractLookup.java; /cvs/openide/src/org/openide/util/lookup/AbstractLookup.java,v <-- AbstractLookup.java new revision: 1.39; previous revision: 1.38 done Checking in src/org/openide/util/lookup/ArrayStorage.java; /cvs/openide/src/org/openide/util/lookup/ArrayStorage.java,v <-- ArrayStorage.java new revision: 1.2; previous revision: 1.1 done Checking in src/org/openide/util/lookup/DelegatingStorage.java; /cvs/openide/src/org/openide/util/lookup/DelegatingStorage.java,v <-- DelegatingStorage.java new revision: 1.2; previous revision: 1.1 done Checking in src/org/openide/util/lookup/InheritanceTree.java; /cvs/openide/src/org/openide/util/lookup/InheritanceTree.java,v <-- InheritanceTree.java new revision: 1.22; previous revision: 1.21 done cvs diff: ArrayStorage.java is a new entry, no comparison available cvs diff: DelegatingStorage.java is a new entry, no comparison available Processing log script arguments... More commits to come... Checking in test/unit/src/org/openide/util/lookup/AbstractLookupArrayStorageTest.java; /cvs/openide/test/unit/src/org/openide/util/lookup/AbstractLookupArrayStorageTest.java,v <-- AbstractLookupArrayStorageTest.java new revision: 1.2; previous revision: 1.1 done Checking in test/unit/src/org/openide/util/lookup/AbstractLookupBaseHid.java; /cvs/openide/test/unit/src/org/openide/util/lookup/AbstractLookupBaseHid.java,v <-- AbstractLookupBaseHid.java new revision: 1.2; previous revision: 1.1 done Checking in test/unit/src/org/openide/util/lookup/AbstractLookupMemoryTest.java; /cvs/openide/test/unit/src/org/openide/util/lookup/AbstractLookupMemoryTest.java,v <-- AbstractLookupMemoryTest.java new revision: 1.4; previous revision: 1.3 done Checking in test/unit/src/org/openide/util/lookup/AbstractLookupTest.java; /cvs/openide/test/unit/src/org/openide/util/lookup/AbstractLookupTest.java,v <-- AbstractLookupTest.java new revision: 1.24; previous revision: 1.23 done Checking in test/unit/src/org/openide/util/lookup/LookupsProxyTest.java; /cvs/openide/test/unit/src/org/openide/util/lookup/LookupsProxyTest.java,v <-- LookupsProxyTest.java new revision: 1.4; previous revision: 1.3 done Checking in test/unit/src/org/openide/util/lookup/ProxyLookupTest.java; /cvs/openide/test/unit/src/org/openide/util/lookup/ProxyLookupTest.java,v <-- ProxyLookupTest.java new revision: 1.5; previous revision: 1.4 done cvs diff: AbstractLookupArrayStorageTest.java is a new entry, no comparison available cvs diff: AbstractLookupBaseHid.java is a new entry, no comparison available Processing log script arguments... Mailing the commit message to cvs@openide.netbeans.org (from jtulach@netbeans.org)