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.
There are some large forms in vcsgeneric module with complex hierarchy and many inner classes. We need to make them simpler so that they can be loaded and initialized faster. The biggest one is VcsCustomizer with 46 inner classes. It takes 2.2 seconds on my machine (PIII 800mHz,512MB) to display its panel in new filesystem wizard for he first time. Possible ways how to improve it: less classes, split panels and initialize WizardIterator lazily if possible. Other candidates are for example vcscore/src/org/netbeans/modules/vcscore/cmdline/RelativeMountPanel vcscore/src/org/netbeans/modules/vcscore/commands/CommandsPool vcscore/src/org/netbeans/modules/vcscore/commands/CommandOutputPanel vcscore/src/org/netbeans/modules/vcscore/util/VariableInputDialog vcscore/src/org/netbeans/modules/vcscore/VcsFileSystem vcsgeneric/src/org/netbeans/modules/vcs/advanced/variables/BasicVariableNode
Is there some proposal how these problems should be solved? Is it intentional, that every class, that builds some UI should be rewritten by hand to change the listener handling? Or will there be some generic utility to do that? The UI listeners cause problems in VcsCustomizer and VariableInputDialog, partially perhaps in RelativeMountPanel and CommandOutputPanel. The other problem are Node properties (BasicVariableNode, CommandNode) I have a feeling, that Petr Nejedly suggested some solution some long time ago, but I can not recall it now. The rest is probably deferred execution to RequestProcessor (RelativeMountPanel, CommandsPool, VcsFileSystem). I'll try to address these cases. BWT: The CommandsPool functionality will be replaced with CommandProcessor (currently on the "experimental" branch), which will be tightly associated with the new VCS APIs. So let's ignore CommandsPool, I'll try to make less inner classes in CommandProcessor ;-)
The UI listeners issue (too many innerclasses) should be solved in issue 24060 - i.e. form editor will provide more effective listeners code, so you just open the form then and let it regenerate the code.
I propose to move this into TEGAL_MILESTONE_3. We've a lot of other work into TEGAL_MILESTONE_2.
I've tried to regenerate the VcsCustomizer form not using anonymous innerclasses for listeners. The result is about 30 less innerclasses, but the effect is minor - under 10%. But I recommend to integrate it anyway.
Created attachment 9009 [details] VcsCustomizer.java
Created attachment 9010 [details] VcsCustomizer.form
Tomas, thanks a lot for the re-generated files. I'm going to integrate them shortly.
The re-generated form committed: /cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/VcsCustomizer.form,v <-- VcsCustomizer.form new revision: 1.26; previous revision: 1.25 /cvs/vcsgeneric/src/org/netbeans/modules/vcs/advanced/VcsCustomizer.java,v <-- VcsCustomizer.java new revision: 1.95; previous revision: 1.94 I'm removing the TEGAL_MILESTONE_3 and leave the issue open for future improvements.
We could use this issue to track all problems with responsiveness of all the new dialogs in VCS support in 4.0 once they are designed and implemented.
The wizard, that adds a new VCS in VCS Manager can have performance issues (it is a reused mounting wizard - see issue #28041 for details).
vcsgeneric is no longer in massive use.