Community
Participate
Working Groups
Looking into why the first time the popup menu of the Navigator view is opened it takes so long. One area that takes about 1/3 of a second is to create the sub menu items of "New" wizard sub menu. In NewWizardMenu, we notice the constructor forces fillMenu() to be called (there is a comment in there saying this is required...is that still so? why?) If we could postpone the creation (i.e calling fillMenu) until the user selects it, this would help performance. I know we are not filling it just to now if the "New" menu item should be enabled because NewWizardMenu::fillMenu will always add New Project... and Other... to the sub menu. NOTES:
PRODUCT VERSION: R 0.9
Defer
Reopen for investigation
Looking at the code it says fillMenu is called in the constructor to initialize NewWizardMenu fields. fillMenu calls getAction for each new wizard action which initializes the actions field. However, getAction is set up to lazy initialize the action. Calling fillMenu in the constructor defeats this mechanism. The only other side effect of fillMenu/getAction seems to be the creation of the actual NewWizardShortcutAction. This sends out property change events when the image descriptor and tooltip text is set.
Commenting out the call to fillMenu does not result in a noticable performance gain. Will need to profile, but I suspect that times will be pretty evenly spread between the various submenus.
As Simon reports NewWizardMenu.fillMenu takes about 1/3 of the time. However, the total time (as reported by JProbe) is just over 60ms on my office machine. Another 1/3 is spent in the Classloader. On my office machine there is no noticable lag the first time the popup menu is shown. Given that removing the call to fillMenu does not noticably speed up the menu opening on my slower home machine I don't think any changes to the menu code are justified. Even on my home machine the lag on first opening is definitely tolerable.
