Bug 61289 - The code folding for tag editors has to be done lazy
The code folding for tag editors has to be done lazy
Status: VERIFIED FIXED
Product: web
Classification: Unclassified
Component: HTML Editor
5.x
All Linux
: P1 (vote)
: 5.x
Assigned To: Marek Fukala
Jindrich Sedek
: PERFORMANCE
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-22 13:41 UTC by Petr Pisl
Modified: 2009-05-18 10:45 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
There is the thread dump (14.13 KB, text/plain)
2005-07-25 09:44 UTC, Petr Pisl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Pisl 2005-07-22 13:41:21 UTC
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.
Comment 1 Marek Fukala 2005-07-25 09:10:39 UTC
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.
Comment 2 Petr Pisl 2005-07-25 09:44:21 UTC
Created attachment 23252 [details]
There is the thread dump
Comment 3 Petr Pisl 2005-07-25 09:45:53 UTC
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. 
Comment 4 Antonin Nebuzelsky 2005-08-31 11:25:42 UTC
This is a beta stopper. Upgrading to P1. Please, evaluate and fix ASAP!
Comment 5 Marek Fukala 2005-09-01 10:43:12 UTC
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
200ms :-).
Comment 6 Marek Fukala 2005-09-01 11:57:09 UTC
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
FoldManager.

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).
Comment 7 Marek Fukala 2005-09-06 14:01:09 UTC
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.
Comment 8 Antonin Nebuzelsky 2005-09-07 08:48:34 UTC
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
Comment 9 Marek Fukala 2005-09-07 11:34:44 UTC
FYI Tondo, you can try to verify it on the participants.html file from Issue
#55541 (approximately 10x faster).
Comment 10 Petr Pisl 2005-09-07 12:10:46 UTC
I verified this issue. There is not the original problme now. It's much faster.
Comment 11 Antonin Nebuzelsky 2005-09-07 12:21:20 UTC
Diky, Petre.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo