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.
Calling ObjectEditor.getTags() on Diff Settings causes DataObjects to be created for the entire services directory. This call may be made several times to instantiate a combobox with the tags in a drop-down. Five calls to ObjectEditor.getTags() in this situation (given a combobox model that proxies PropertyEditor.getTags() and also needs to call this to get the length of the list of properties) take about 3 minutes to complete on my laptop, during which the UI is blocked. For now, I have added caching of tags to my inplace editor combobox's model, so this work is only done once, but even calling it once is extremely slow. At minimum, 2-3 calls to this method are necessary to set up a property editor - 1st, to decide if a combo editor should be used (if getTags() is non null), 2nd when the combo editor model's size() method is called, and 3rd when returning the tags. Two optimizations are possible, both of which should be implemented: 1. The getTags() call in ObjectEditor can check for the attribute "SystemFileSystem.displayName" on the primary files under the folder and avoid doing any further work in the case it is present. 2. Create an extension interface to EnhPropertyEditor which includes the call "getTags (Filter someFilter). Use this interface for property editors like ObjectEditor, which can have very expensive getTags calls. This is probably more efficient design than first returning the entire services folder content, and then requiring it to be filtered elsewhere. If we do that, two optimizations of the filtering process are possible: 1. The primary files can be examined for attributes "instanceOf" or "instanceClass" and the display name returned as appropriate. 2. If those attributes are not present, the class can be found using Class.forName() and it can be tested for assignability to the property class, and any non-matches can be discarded. Attached are relevant stack traces taken during the three minute delay due to calls to getTags(). CC'ing Martin Entlicher, in case there is something specific about the way Diff settings are implemented that is making this problem worse.
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