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.
Beginning of action: Click ... button (an EE-specific property is suggested) (first time this session) Initial Feedback: Button appears pushed Maximum time allowed: 100 ms Second Feedback: Dialog box appears Maximum time allowed: 1000 ms
Marian's measurement (time in milliseconds): conditions: - SUN UltraSparc60 / 512 MB RAM / Solaris 5.8 / CDE - JDK1.4.1(01) - [nb_dev](200211140100) , MDI - mounted sampledir bring up extrnal operator Main - Arguments (String editor) 201 132 147 Color PE 1465 1447 1174 Test cases described on page : http://performance.netbeans.org/qa/TestSuites.html#bring_up_Arguments_editor
changing subcomp to property editors, passing to Tim. Also note that results of measurements shows that only some of prop editors are unresponsive (pls compare development x qa measurements, find out if some numbers differ dramatically and why) http://performance.netbeans.org/reports/20020919-dialog-numbers.txt
What does "external property editor" mean? One in a dialog? Can you recommend an EE specific property editor to look at?
Tim , in my opinion it's about all property editors with own dialogs, like Color Property Editor, Icon property editor, .... .
reassigne to Tim, new owner of property editors.
See the class ReusableDialog in the property sheet rewrite branch. It contains some experimental code to bring up a dialog in a "please wait" state while the contained component is created on a separate thread. Further work is needed, as the code needs to decide when to use a thread based on some metrics that either it creates and saves, or that are provided for it, but it should be possible to make it self-tuning over time that takes into account the overhead of classloading on first invocation. Some baseline metric needs to be found during startup (find some usually expensive piece of work that does not change with number of modules and time it) which can be used as a factor in the decision to create/not create the component off the AWT thread. Any suggestions of something that could be used for this? Also, caching and reusing things like the color editor will help - the color editor in particular is extremely expensive to create (and its "recent colors" function is broken because the same instance is not reused). A wholesale replacement for this editor or a much better inplace editor for colors would also help.
FYI, I added some logging code to ReusableDialog to see how much time was spent in somePropertyEditor.getCustomEditor() on my Ultra60. Aside from classloading on first invocation, most editors are fairly well behaved. The following classes are the poorest performers: org.netbeans.beaninfo.editors.ColorEditor$NbColorChooser - +/-1 second on first invocation, a little over 1/2 second on second org.netbeans.beaninfo.editors.ServiceTypePanel - +/- 1/2 second first invocation, 60ms second invocation, ~20ms later invocations. Appears to be weakly cached somewhere, as the time goes back up if not invoked for a while. org.netbeans.modules.form.FormCustomEditor - 851ms first invocation, ~200 later invocations org.netbeans.beaninfo.editors.PropertiesCustomEditor (looks like classloading for the props editor) - 912ms first invocation, ~35 later invocations Note that it may only be possible to use the ReusableDialog approach for classes known *not* to return a Window subclass from getComponent(). This is probably solvable through the XML registration process.
Created attachment 8526 [details] Timing data on ultra 60 for custom property editor creation
Fixed in trunk. Now displays wait cursor immediately when the button is pressed, and restores the cursor once it is displayed. It may be possible to do some further optimizations with the property sheet rewrite.