When I close NetBeans with an open file like this:
http://web.netbeans.org/struts/struts-support-ui-spec.html and then try start
the IDE again , the startup takes more then 90 seconds and more than 60 seconds
takes the folding for the last opened file. So the first code folding should be
done after displaying the editor.
The code folding is of course done lazily. I cannot influence the time when the
FoldManager framework requests the folds to be created. I will investiga it.
Created attachment 23252 [details]
There is the thread dump
I attached the thread dump. There is a html folding before opening the main
window. I think it's editor issue not html issue, but should be solved.
This is a beta stopper. Upgrading to P1. Please, evaluate and fix ASAP!
I am going to fix it now. Just note that the Issue #55541 has already been fixed
so now the generation of folds for the struts-support-ui-spec.html takes about
Current situation is as follows:
1) the FoldManager instance is initialized when the editor's TopComponent is
being initialized. The FoldManager.initFolds() method responsible for the folds
initialization is called from within the editor module code.
2) in the initFolds() method there is a new TimerTaks's thread created with
Thread.MIN_PRIORITY + 1 priority and via the j.u.Timer is scheduled to execute
after 1000ms. So in fact the code immediately returns back from the initFolds()
method - nothing is blocked.
3) After the parsing in background thread is finished the foldhierarchy is updated.
The most time consuming action is the #2 but it DOES *NOT* block any other
thread run during the IDE startup. The same mechanism is used in java's impl. of
As I already mentioned, the Issue #55531 has been fixed so the times of the
folds generation are much more shorter.
Probably the biggest problem here is the thread concurrency on linuxes, where
the Thread priority doesn't play a big role. So even I run the parsing with
MIN+1 the thread can slow down the other things running in the moment. Note that
this is clearly visible from the Petr's threaddumpl that the id wasn't repainted
because of the folding itself but because of some other code likely slowed down
exceedingly by the folding thread.
Please let me know your objections against the current implementation otherwise
I will close this issue is FIXED (in respect to Issue #55541).
Since noone from performance team didn't rise any objections for a week I am
going to close this issue. As I already mentioned since the biggest problem with
slow HTML folding has been fixes I consider this issue as fixed. If anyone has
an objection please reoped as soon as possible.
Petre (ppisl), please, verify with your usecase. I was trying to measure a
difference between startup with your html file for builds with/without the fix
of issue #55541, but did not notice any change. Anyway, the startup was fast in
both cases for me, so in fact I was not able to reproduce this problem. So, I'd
need you to verify this is fixed... THX
FYI Tondo, you can try to verify it on the participants.html file from Issue
#55541 (approximately 10x faster).
I verified this issue. There is not the original problme now. It's much faster.