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: | ObjectEditor.getTags() forces instantiation of everything in services directory | ||
---|---|---|---|
Product: | platform | Reporter: | _ tboudreau <tboudreau> |
Component: | Property Editors | Assignee: | _ tboudreau <tboudreau> |
Status: | VERIFIED INVALID | ||
Severity: | blocker | CC: | jglick, mentlicher, pnejedly |
Priority: | P4 | Keywords: | PERFORMANCE |
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | Stack traces during hang while editor is fetching tags |
Description
_ tboudreau
2003-01-06 10:03:05 UTC
Created attachment 8451 [details]
Stack traces during hang while editor is fetching tags
David Strupl mentions that the issue may be partly that my new property sheet impl is not using our full enhancedPropertyEditor API, so in a normal situation, filtering already in place should take care of this. I'm not marking this as invalid yet, since ObjectEditor does seem to be causing incredible amounts of work to fetch its tags, and probably this can be cleaned up some (i.e., my first suggested patch). Umm, ObjectEditor uses Template for the lookup, so if the template is properly passed, the lookup should return only few items. (properties[0].setValue ("superClass", Diff.class);) How many entries end up in the combo? How many other modules do use ObjectEditor for selecting instance of a service? I have changed version from 4.0 dev to S1S 4.2 (Nevada). Agree with Petr here, if you set the superclass then instanceOf should be used to filter out everything which is not of the appropriate type, quickly. Default folder lookup should already know the superclasses of everything in Services, and a call like getTags should take only a few milliseconds. Caching tags in the property sheet impl is probably a good idea in general, but it should not matter much here. Figure out what is broken here before proposing all sorts of new APIs... Changing priority as this is probably invalid. Keeping this open as a reminder to make some measurements - if instantiating the entire folder is slow, instantiating only the things the filter wants probably isn't that fast. Closing as invalid; the performance is satisfactory with a filter (there are other reasons why I'd like to kill ObjectEditor, after spending 5 hours fixing bugs in it last night, but that's another story). Tim is right. verified |