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: | The code folding for tag editors has to be done lazy | ||
|---|---|---|---|
| Product: | web | Reporter: | Petr Pisl <ppisl> |
| Component: | HTML Editor | Assignee: | Marek Fukala <mfukala> |
| Status: | VERIFIED FIXED | ||
| Severity: | blocker | CC: | issues, pjiricka |
| Priority: | P1 | Keywords: | PERFORMANCE |
| Version: | 5.x | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Attachments: | There is the thread dump | ||
|
Description
Petr Pisl
2005-07-22 13:41:21 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. 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 200ms :-). 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). 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. Diky, Petre. |