Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 144426 - Menu only usable after 3-5 seconds
Menu only usable after 3-5 seconds
Product: platform
Classification: Unclassified
Component: Actions
All All
: P3 (vote)
: 6.x
Assigned To: Jaroslav Tulach
Depends on: 150875 158269 159659 159661
  Show dependency treegraph
Reported: 2008-08-19 18:22 UTC by mrmorris
Modified: 2009-03-06 15:42 UTC (History)
8 users (show)

See Also:
Issue Type: DEFECT

I am able to initialize menu and toolbar outside of AWT, in case this would help (17.62 KB, patch)
2008-09-02 09:22 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mrmorris 2008-08-19 18:22:08 UTC
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.
Comment 1 adam_myatt 2008-08-19 21:25:46 UTC
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.
Comment 2 mengweili 2008-08-20 01:13:26 UTC
I have the same problem.
Comment 3 Lukas Hasik 2008-08-20 10:18:18 UTC
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.
Comment 4 mrmorris 2008-08-20 11:46:17 UTC
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?
Comment 5 mrmorris 2008-08-20 11:54:49 UTC
To back up my point. Following nbusers@, there seems to be a backlash against these artificial performance tricks among
existing NetBeans users:
Comment 6 Milos Kleint 2008-08-20 12:31:06 UTC
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.
Comment 7 adam_myatt 2008-08-20 15:30:16 UTC
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.
Comment 8 mithun_gonsalvez 2008-08-21 02:41:51 UTC
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....
Comment 9 Andrei Badea 2008-08-22 20:42:52 UTC
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.
Comment 10 Jaroslav Tulach 2008-09-02 09:22:00 UTC
Created attachment 68829 [details]
I am able to initialize menu and toolbar outside of AWT, in case this would help
Comment 11 Jaroslav Tulach 2008-09-24 12:47:36 UTC
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.
Comment 12 Jaroslav Tulach 2009-02-03 14:32:28 UTC
One reasons why AWT is blocked after startup is initialization of Java Editor Kit. Moving the slowest part outside of 
AWT: ergonomics#0373b4b70a3c
Comment 13 Quality Engineering 2009-02-04 21:19:10 UTC
Integrated into 'main-golden', will be available in build *200902041526* on (upload may still be in progress)
User: Jaroslav Tulach <>
Log: #144426: Preinitializing JavaKit outside of AWT
Comment 14 Jaroslav Tulach 2009-03-06 15:42:14 UTC
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.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo