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.
Menu not working, or responsiveness excruciatingly slow for 3-5 seconds after the UI has come up and splash screen is gone. This appear to be the result of aggressive lazy-loading of actions implemented sometime around the 6.0 code base, in order to boost apparent start-up time. However the net effect of this is that the general feel of responsiveness suffers tremendously having to wait an arbitrary amount of time before the menu can actually be used. Consider extending the time splash screen is shown or at least disable the menu such as not to suggest to the user it's ready when really it is not.
I've also seen this problem. After loading NB for first time with an open project, I try right clicking on the project name to do something and get a tiny menu that is initializing. then have to wait a few seconds for scanning, etc. to finish before full project context menu is available.
I have the same problem.
afaik, this is desired behavior that should speed up NB start up. That is a trade-off - you can either start up IDE very fast and initialize lot of things later or you can start it slowly with all the components initialized. IMO, we cannot satisfy everybody there will be always two groups of users - 1, interested in startup time 2, interested in responsiveness after startup. Please, take in mind that when you had open lot of project in the IDE then the start up time multiply. However all the projects will be initialized in background after startup. And you will notice the background initialization only if you want to browse a project.
I realize why it was done (assuming the vast amount of people who voted using the NetBeans satisfactory poll wanted faster startup). However I question whether people really meant "it's ok to trade off startup speed with usability". If a component has been realized and is visible on screen, it should generally be ready for input. Particular during module development this new behavior has a very negative and heavy feel to it. As I mentioned, perhaps let all proxied/fake Actions be disabled such as not to misguide the user. Or add a setting in the options such that lazy-loading can be turned off?
To back up my point. Following nbusers@, there seems to be a backlash against these artificial performance tricks among existing NetBeans users: http://markmail.org/search/?q=Pretty+Much+Unusable&q=list%3Aorg.netbeans.nbusers
re adam_myatt I share the opinion that lazy loading of projects didn't really help much in terms of perceived performance. We shall not be optimizing for an artifacial goal of "show the netbeans window fast". whenever I start an ide I need to get back into context of what I've done before, that usually doesn't mean editing an opened file unfortunately. I want to browse to a file, check the mercurial/subversion for modified files and see what I modified last. Often it involves pulling new versioning changes in, rebuilding the projects involved etc. For anything like that, I need the projects to be fully initialized. In 6.1 I knew that when main window opens, I can start working. Now it's not the case and the line between when the IDE is ready is pretty blurred. That results in me starting the IDE and go away to cook tea, read news or do whatever takes some time. Then I check back with the IDE, just to get hit by the filesystem refresh that happens on refocusing the IDE's frame. Another perceived slowness and performance problem. on the technical level, lazy loading of projects created a more complex codebase that introduced new (sometimes intricate) bugs and is harder to maintain and change.
I understand the different concerns in startup performance vs usability. Just my minor (and only very minor) complaint was when opening NB with few projects open the right-click context menu on a project is not immediately available sometimes on startup. Too often I close NB at the end of the day with one or two projects open and the next day when NB opens I need to either close a project, or set one of the projects to main, or edit the properties of one of the projects right-away. If the tradeoff of the project context menu lazy load is better startup time, so be it. :) just wondered if there was any way to have other project menu options visible right away even if clicking them caused a pause. at least during the 1-2 seconds my eyes scanned the project context menu looking for the correct menu item the corresponding panels/code would have time to lazy load like you mention.
This should be done in such a way as Eclipse does it, It should have an index file or some thing which should be read and not the complete directory structure. If required, it can have a background thread which will do the indexing when the NB or Processor is used lightly.... When there is a Huge Source [Single Project] of about 8000 to 9000 files in the project the time that the user has to wait for the Scanning to complete for the Menu to show up is a bit too much. Please NOTE: In some cases when the Menu comes up. But any operation on the menu will make you wish that you did not see the menu in the first place....
I agree with mkleint on the (ir)relevance of the "show main window quickly" goal. To me, the startup time is the time between typing "netbeans" in the terminal and the CPU and disk usage going back down to zero, so that I can start typing, opening files, using code completion, etc. Whether there is a splash screen saying "opening projects", "scanning", etc., or these message appear in the main window, is completely irrelevant. I read news during this time anyway.
Created attachment 68829 [details] I am able to initialize menu and toolbar outside of AWT, in case this would help
A bit too risky fix for 6.5 without guaranteed success. Unless there is really strong need to do it, I'll wait till 6.5 is branched.
One reasons why AWT is blocked after startup is initialization of Java Editor Kit. Moving the slowest part outside of AWT: ergonomics#0373b4b70a3c
Integrated into 'main-golden', will be available in build *200902041526* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/0373b4b70a3c User: Jaroslav Tulach <jtulach@netbeans.org> Log: #144426: Preinitializing JavaKit outside of AWT
I guess the problem is much improved by itself as issue 30121 is fixed. Still the issue found while fixing this one shall be addressed.