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.

Bug 130171 - Editor's initialization blocks AWT for too long time
Summary: Editor's initialization blocks AWT for too long time
Alias: None
Product: editor
Classification: Unclassified
Component: Actions/Menu/Toolbar (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jaroslav Tulach
Depends on:
Reported: 2008-03-14 15:55 UTC by Jaroslav Tulach
Modified: 2008-03-28 10:46 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Patch for warming up editor kits (4.27 KB, text/plain)
2008-03-19 09:59 UTC, Vitezslav Stejskal

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2008-03-14 15:55:37 UTC
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.
Comment 1 Jaroslav Tulach 2008-03-14 16:26:51 UTC
I've implement change like this we will be able to speedup opening of main window by ~5s from 32s after cold startup.
Comment 2 Jaroslav Tulach 2008-03-14 16:37:06 UTC
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.
Comment 3 Jaroslav Tulach 2008-03-14 17:00:34 UTC
The property works since build bc91c6553b7e
Comment 4 Jaroslav Tulach 2008-03-14 17:33:54 UTC
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.
Comment 5 Vitezslav Stejskal 2008-03-17 13:29:57 UTC
Ok, thanks for the measurements. Let's see what we can do about it.
Comment 6 Vitezslav Stejskal 2008-03-18 12:35:40 UTC
We need to watch for regressions like issue #130272 for example.
Comment 7 Vitezslav Stejskal 2008-03-18 13:34:35 UTC
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
Comment 8 Vitezslav Stejskal 2008-03-19 09:58:05 UTC
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.
Comment 9 Vitezslav Stejskal 2008-03-19 09:59:06 UTC
Created attachment 58636 [details]
Patch for warming up editor kits
Comment 10 Jaroslav Tulach 2008-03-19 20:11:12 UTC
changeset:   74261:105824cd6075
tag:         tip
parent:      74260:0c3e24bd6df8
parent:      74188:23bd54dd4a41
user:        Jaroslav Tulach <>
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
Comment 11 Jaroslav Tulach 2008-03-19 20:13:30 UTC
changeset:   74262:17cc7ac94176
tag:         tip
user:        Jaroslav Tulach <>
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. 
Comment 12 Vitezslav Stejskal 2008-03-20 11:30:25 UTC
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?
Comment 13 Jaroslav Tulach 2008-03-21 12:31:09 UTC
OK, ask for FTR. As far the speedup goes, I am still waiting for independent measurements. My own shown ~10%.
Comment 14 _ theanuradha 2008-03-28 10:46:40 UTC
on my Windows 1.6G Laptop it is around ~20%