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
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
Integrated into 'main-golden', will be available in build *200902041526* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jaroslav Tulach <email@example.com>
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.