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.
After startup I often see the ide to be unresponsive. I believe that the reason is that AWT thread is blocked by some long running operation(s). I will attach stacktrace to show that the problem could be in invoking SystemAction.getMenuPresenter in AWT thread. I belive that this could be optimized and run the getMenuPresenter from another thread and just the AWT hieararchy update in AWT thread.
Created attachment 8579 [details] Thread dump
Using two-way init with proper waitFinished to avoid deadlocks. Checking in MenuBar.java; /cvs/openide/src/org/openide/awt/MenuBar.java,v <-- MenuBar.java new revision: 1.48; previous revision: 1.47
verified in [nb_dev](20030129)
Huh, someone fixing #32060 forgot to reopen this one.
Petr, reopened issue, evaluate it again, thanks...
> ...the problem could be in invoking > SystemAction.getMenuPresenter in AWT thread. Minor note - remember that constructing components in non AWT threads is dangerous
Sorry, I really can't fix this. As the AWT may need to synchronously wait for the creation task to finish (e.g. because user clicked on the menu quickly), I can't split the loading task to background loaders part and small AWT subtasks - the background task may be waited on from AWT, which would prevent it from finishing its owt AWT subtasks. The subtasks have to be AWT as you have to create the components in the AWT thread.
Even if you are not able to fix it it does not mean that it should not be fixed. I am not sure about your rules for WONTFIX but it should IMHO stay open until someone is able to fix it. Are you saying that having the AWT blocked for 1-5 s during startup is ok? I don't agree. Maybe not P2 but P3, with PERFORMANCE keyword maybe P2 is correct.
It is not that *I* am not able to fix it. *It* is impossible to be fixed. Once you have to create the component in AWT, and creating the component takes long time, you can't do anything about it. The only alternative is to prepare the menu synchronously during startup and even in that case the AWT would be blocked.
Are you serious that this has to stay as it is now? As I said this has to be fixed some day. Feel free to decrease the priority if you feel that way but please leave it opened.
We run a warmup task immediately after startup that initializes all the "lazy" menus anyway. Deleting code reduces potential bugs, and there's no reason to have lazy menus if we are going to immediately defeat the purpose anyway. Petr, is there is any real value left in lazy menus? I think we should kill both the lazy menus and the warmup task to initialize them - if it makes startup slower, at least we know what we *really* need to optimize; in the meantime, we kill a bunch of pointless code that is doing more work than it would take to just initialize menus in a normal way.
As per nbdev suggestions by Tim and Ivan reopenning for further reevaluation. You have several options here: 1. decrease priority 2. choose different target milestone 3. reassign to someone else -- all of these would make your statistics look better. To really close it it would be good to know what takes around 1 second (several times during startup) that has to be done in the AWT event queue. I am really curious. Or persuade me that it is no longer the case in current dev build - but in this case please mark as INVALID.
I don't care about stats, but it doesn't influence IDE users, so it is not a priority for me. Of course patches welcome at any time, preferabely with tests ;-) I have not measured blocation over 1s myself in the current IDE after the main window is displayed, but I have not measured it thoroughly.
It affects IDE users: try for example drag some window of some other app over the just launching IDE. The user will notice it is not repainting and will think that the IDE (or Java) is slow. Let's go to .NET, Eclipse, ...
Well, forgive me trying to be chytry about this, Petr, but you've probably measured it. Where is the actual bottleneck? - Resolving the instances from the InstanceDataObjects - Classloading because of that - Constructing the presenters What?
David: > It affects IDE users: try for example drag some window of some > other app over the just launching IDE. So you mean splash screen? That is not related to lazy menu at all, lazy menu is computed after the main window is shown. That would most probably be winsys issue, but I woudn't recommend WS folks to run the WS initialization in any other thread. You can try to convince them though...
Tim, > Where is the actual bottleneck? The times are less than few hundreds millis per one menu (it was more than 100ms, so it needed warmup). The time spent there is distributed between classloading (10 menu items means 10 actions to be loaded, which means probably about 20 classes), bundle parsing (10 menu items means typically 3-5 nontrivial bundles to be parsed) and icon loading. You can try to feel it yourself using -J-Dnetbeans.warmup.skip=true. I've just checked (not profiled) it on my current HW and the worst case was the windows menu (216ms), rest was mostly below 100ms. As I haven't profiled it, I can only guess the windows menu slowness comes from the fact that each entry is comming from different module, uses icon and have to parse a bundle. Of course part of the time is the folder instance processing, but it is hard to separate it because of the inlined instance creation.
Still a problem?
It should not be problem in general. Actions.alwaysEnabled should help here.
> It should not be problem in general Does that mean it actually isn't one? :-) If the I/O to load the folder is still happening in the event thread, it probably would at least be beneficial to the loading part in the background, although that may be impossible for things that actually instantiate Swing components (Action instances, though, could be initialized elsewhere). Otherwise doing the I/O can theoretically block the AWT thread for any amount of time.
Oh, damn, we are even loading the classes in AWT! Shouldn't we replan all the class loading I/O off the AWT queue too? ;-) Seriously, there are limits. SysFS I/O (of the declarative stuff, not explicitly large userdir data) shouldn't be considered more evil that class loading. It is usually of the same kind: Load a small resource from the installation archive once during the runtime. If you _install_ on a network drive and your network is busy/crappy, AWT will be blocked all the time for the first few operations after the startup.
I guess my patch http://www.netbeans.org/nonav/issues/showattachment.cgi/68829/ActionsInitedOutsideOfAWTThread.diff would move the classloading and also creation of instances out of AWT. But unless really needed, I leave the change after 6.5.
Created attachment 77801 [details] New patch, but not final. This one is not stable enough.
core-main#8f4d5b726d43
Integrated into 'main-golden', will be available in build *200903070353* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/8f4d5b726d43 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #30121: Initializing action instances in background thread, only then switching to AWT one to create their presenters