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.
While running a profiler over the threaddemo, I was surprised to see that most of the CPU time was spent in Lookup-related methods. This was odd since I did not do anything which required Lookup in any way: just opened a tree of LookNode's and browsed it; no property sheet showing, no actions to enable, etc. Seems that getLookupItems is called as soon as the LookNode is displayed, even when the results will never actually be used. This is a terrible performance bug; getting lookup items tends to be relatively expensive, compared to methods like isLeaf, getIcon, getDisplayName (depending on the application of course). I think people on dev@projects have been complaining about the same thing but I don't see anything filed. From what I understand, getLookupItems is used as part of the Lookup which is passed back to other methods in the Look. (Still don't really understand why a Look would need to be passed cookies which it presumably already has access to, but that is a matter for documentation and use cases I suppose.) But my understanding was that the Lookup passed to other Look methods was supposed to be lazy, and not call getLookupItems at all unless and until someone made some query against this Lookup. Clearly that is not the case. This should be fixed and confirmed with a unit test.
Created attachment 11457 [details] Stack trace fragment displaying problem
Known problem. Hrebejk has a working fix on his harddisk. However he is waiting for application of two_storages_32203 branch from issue 32203.
I have a similar problem: i register an InstanceContent.Convertor into lookup of Project. The convert() method returns null for anything else then one private class in j2eeserver module. It gets called with this class as a parameter when the project node is created. I will attach stack trace.
Created attachment 11467 [details] stack trace
For Pavel's issue and (stack trace) evaluation please see issue #35834
The lookup was initialized when any method on LookNode was called. This should not be the case now.
closed