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.
According to my measurements the initShortcuts folder takes more than 5% of startup ~600ms from 7s startup, which seems way to much for me. Here is the log (you need revision 454ea214beeb): [exec] @5916 - Main window initialization started [exec] @5927 - Timer initialized dT=11 [exec] @5929 - initShortcuts started [exec] @6557 - initShortcuts finished, took 628ms [exec] @6557 - Shortcuts initialized dT=0 [exec] @6558 - Main window initialization finished, took 642ms [exec] @6558 - Main window initialized dT=0 [exec] @6560 - Window system initialization dT=2 [exec] @6616 - Security managers installed dT=56 [exec] @6642 - Ran any delayed command-line options dT=26 [exec] @6642 - Splash hidden dT=0 [exec] @6642 - Preparation finished, took 6640ms [exec] @6642 - Main.main finished dT=0 [exec] @7050 - Window system loaded dT=408 I guess this should be eliminated a bit.
ShortcutsFolder doesn't belong to winsys, i don't know who is maintaining it at the moment.
Created attachment 67930 [details] Attempt with LazyAction
The patch http://www.netbeans.org/nonav/issues/showattachment.cgi/67930/X.diff speeds up the start time, the resolution takes about 400ms now ~ 3% of startup time. However the trouble is that then actions in menu do not have their shortcuts (until they are invoked by the shortcut ;-). The current system of actions seems to require to instantiate all actions with shortcut on startup and assign them the shortcut. That means I will have to try another approach. The patch is here just as a proof of what does not work.
After deep investigation it seems that this one will be hard issue to address for 6.5. Most of the time is spend in InstanceDataObject.instanceCreate - this includes classloading, reflection that is used to create the actual instances of the actions. This is unavoidable in current actions design (for all actions other than Actions.alwaysEnabled). There may be slight optimizations, like reducing the number of reflection (for example debugger is accessed 10-20 times), however the effect is unlikely to be huge. Anyway the fix seems to be more in the global changes across all modules, so I am moving this issue to performance category for now.
We have a test that measures # of reflective usage: http://hg.netbeans.org/main/rev/73c666fed203 It can help us from watching over regressions, however we are not able to fix much. Most of the time here is spend in classloading of Actions - to prevent that, we would probably need declarative ones. Let's think up the plan for next release.
Possibly fixable including accelerators (without use of Actions.alwaysEnabled) by completely inverting how we deal with shortcuts, as proposed in issue #152576. *** This issue has been marked as a duplicate of 152576 ***