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.
Summary: | Editor's initialization blocks AWT for too long time | ||
---|---|---|---|
Product: | editor | Reporter: | Jaroslav Tulach <jtulach> |
Component: | Actions/Menu/Toolbar | Assignee: | Jaroslav Tulach <jtulach> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | mmirilovic |
Priority: | P2 | Keywords: | PERFORMANCE |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | Patch for warming up editor kits |
Description
Jaroslav Tulach
2008-03-14 15:55:37 UTC
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% |