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.
The initialization of editor slows down startup. While investigating what is taking so long, I found out that when CloneableEditor is shown, it prepares the whole document in AWT, loads whole its toolbar, and other settings etc. This all blocks AWT thread, so we cannot open main window, neither the user can do anything else with the IDE. I have prepared small rewrite (right now conditionally turnable by a property) that shows what to do. E.g. start a background thread, warm up the editor there, and then go back to AWT to quickly set things up. However with current state of the art, the initialization in AWT still takes 12s. We need to move things away from this phase and put them into the pre-warm up one. And here I need your help or at least guidance, as I do not know the internals of editor very well.
I've implement change like this we will be able to speedup opening of main window by ~5s from 32s after cold startup.
To try yourself. Start the IDE, open one project, open one of its files, close everything else in the editor area. Closer. Start with parameter -J-Dorg.openide.text.CloneableEditor.newInitialize=true Open timers/counters window and there shall be a node showing how much time it took to "Open Editor", devided by each phase. 0 in run in request processor prepares as much as possible, 1 in AWT shows the editor (this one shall be as fast as possible), 2 mangles with annotations and can be delayed.
The property works since build bc91c6553b7e
Oleg just did measurements on my previous attempt that just delays loading of editor content. Here are the results: > regular build > full with opened project, 1 opened java file in editor - average 29826 ms > basic with opened project, 1 opened java file in editor - average 21509 ms > > build with changed jars > full with opened project, 1 opened java file in editor - average 24349 ms > basic with opened project, 1 opened java file in editor - average 17890 ms if we delay loading of editor and start processing it only when the main window is shown, we can get ~25% speedup. Of course we cannot be that good, but if we do things well, I am sure we can get to 15-20% and I am ready to help with achieving this goal.
Ok, thanks for the measurements. Let's see what we can do about it.
We need to watch for regressions like issue #130272 for example.
I did some measurements myself simply by measuring time spent in various parts of CE.DI.initVisual(). The results were (not surprisingly) different when opening a file for the first time and when subsequently opening other files of the same type. Since we are focused on reducing the startup time we should be more concerned about the times for opening a file for the first time. It looks like the most expensive are setEditorKit and initCustomEditor followed by initDecoration and setDocument. Here is a summary of what those particular calls do: 1. setEditorKit - a lot of initialization including the scanning of all colorings for the font size and loading a couple dozen of settings 2. initCustomEditor - creates all side bars registered for the editor's mimetype 3. initDecoration - creates editor toolbar by loading all its actions, initializing shortcuts, etc 4. probably does again some of the things done in #1 #2 and #3 by its nature has to run in AWT, beacuse it's initializing a lot of Swing stuff. There might be things in #1 that does not have to run in AWT or that could be spead up - namely initLineHeight(). * First open of a file: setEditorKit took 100msec setDocument took 26msec initCustomEditor took 109msec initDecoration took 39msec The rest of initVisual took 0msec * Subsequent open of a file of the same type: setEditorKit took 54msec setDocument took 16msec initCustomEditor took 9msec initDecoration took 4msec The rest of initVisual took 0msec
Yardo, I managed to move some MimeLookup related stuff from initVisual to initNonVisual and I think it improved the times. I'd like to ask you for help. Could you please take the patch I am going to attach here, apply it to your sources and do your measurements again to see how much (if at all) the times improved? You will be much more efficient on this than I, because you know what and how you measured previously and probably still have the environment available. If the patch works we can polish it somehow - I don't like 'NbEditorKit implements Callable'. I would rather use reflection, even though it's a bad practice. I'm open for suggestions here.
Created attachment 58636 [details] Patch for warming up editor kits
changeset: 74261:105824cd6075 tag: tip parent: 74260:0c3e24bd6df8 parent: 74188:23bd54dd4a41 user: Jaroslav Tulach <jtulach@netbeans.org> date: Wed Mar 19 20:09:00 2008 +0100 summary: Accepting Vita's code to pre-initialize the EditorKit, documenting it and writing tests to verify this contract is honored in future
changeset: 74262:17cc7ac94176 tag: tip user: Jaroslav Tulach <jtulach@netbeans.org> date: Wed Mar 19 20:12:02 2008 +0100 summary: Rest of Vita's commit Btw. if you do not like the Callable API, rather than reflection I'd like to create an NbDocument.WarmUp interface, if you want to do that, then go on.
Well, NbDocument.WarmUp would be better than just Callable, which is too generic. But then, would I be supposed to implement NbDocument.WarmUp on the kit? Or on the document? It would probably make more sense if the document implemented it. We would just have to make sure that the document's 'mimeType' property is initialized prior the call to NbDocument.WarmUp's method (whatever its name would be). If you agree with this approach I'll reopen this, attach a patch and ask for an FTR (aka Fast Track Review :-). P.S.: Just out of the curiosity, how much faster is the startup now?
OK, ask for FTR. As far the speedup goes, I am still waiting for independent measurements. My own shown ~10%.
on my Windows 1.6G Laptop it is around ~20%