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.
Development build #200502241900 of NetBeans 4.1 Windows XP, JDK 1.5.0_02 build #05 Description: ============ User must be extra patient when editing long XML files. There is a certain usecase described below causing editor to hang for some time every two seconds and CPU consumption reaches ~90%. Steps to reproduce: =================== 1. Create new sample web application project. 2. Save attached HTML in the project and open it. 3. At line 27 type < and press & hold e.g. A key. 4. You should observe significant delays after a while occuring after every ~2 seconds.
Created attachment 20522 [details] HTML file where this bug should be reproducible.
Changing summary a bit ... :-)
I will take a look at it. I found some performance regression caused by my yesterday's fix regarding matching of singleton tags. I have a fix for this, but this speeds the editor only little. It still needs more investigation. Thanks for reporting this.
Partially fixed - tag matching is now more effective. There is a problem when user writes a tag name and there is not any end tag for this tag. In such a case the document is scanned from the edited line to the end (or to the first line in case of end tag writing) of the document. The scan is done after each typed or deleted character of a tag name. Checking in HTMLSyntaxSupport.java; /cvs/html/editor/lib/src/org/netbeans/editor/ext/html/HTMLSyntaxSupport.java,v <-- HTMLSyntaxSupport.java new revision: 1.10; previous revision: 1.9 done
The delay happening aproximately every two second when writing into the editor is caused by a garbage collector cleaning a huge number of objects allocated during typing. The problem is not caused by neither folding nor page parsing by jasper. Note that the problem is more generic - it happens also in JSP files when typig jsp tag names. The most probable culprit is tag matching.
The problem is created by editor's 'matching block' functionality. Every character typed into editor means that a matching pair is searched (method SyntaxSupport.findMatchingBlock() is called). For JSPs and HTML files this method parses the entire document - it creates a chain of TokenItems object. If the file is big enought and moreover no matching tag is near the cursor (for example when you use a tag which doesn't have an end tag) the tokechchain involves a huge number of TokenItem instancies. The problem is that these instancies are linked to each other by hard references so even if there is no reference to the token chain the garbage collector in its first scan (when objects are moved from even to survive 1,2) doesn't recognize that the chain should be garbaged and moves those objects into old gen space. And after the old gen heap space is full the GC runs 'full scan' over the old gen objects which results in the mentioned noticable delays. The problem seems not to have a trivial solution so a quite workaround fix can be to not to call the findMatchingBlock method after each typed character, but wait for a time, e.g. 500ms. This has to be done on the editor module side => reassigning. Note that when you disable the concurrent mark and sweep garbage collector the problem is much more visible.
Setting TM to promoF.
I'm experiencing huge performance decrease when editing large html files (> ~2000 lines), sometimes the IDE won't get overdrawn for 5 minutes or longer. (On a SunBlade 2000). Maybe there is a connection with this issue. I'll add a thread dump (get when the IDE was locked). ------------- 4.1 && 4.2 dev 200506021800 Solaris 10 on Sparc, JDK 1.5.0_03
Created attachment 22475 [details] thread dump log file
can you please attach the HTML file. From the stack it is obvious that there is running a thread which computes html folds. However the thread runs on a very low priority so it should not cause the IDE to not to redraw. It would help us to have your file so we would be able to reproduce the problem and hence fix it.
Created attachment 22479 [details] example html file
Have the html file opened in the IDE along with any other file, and try to switch between these files in the editor. Thanks for your effort.
I have tried it and confirm that it is really unusable. There are however two known workarounds at the moment: 1. Disable code folding when editing files of this size. 2. Make sure every open tag has corresponding end tag though it is not required e.g. use <br></br> instead of only <br> - this made the scan ~5 times faster We are investigating possible cause of this response problem and will try to deliver patch soon.
The folding thread used to run on priority *Thread.NORMAL* so it slowed the repainting down quite heavily. I have integrated a hot-fix for this issue. Now the folding thread *really* runs on Thread.MIN_PRIORITY + 1 => changing priority to P2. Now user can work with the ide normally although the folds creation spans ages :-). I will rewrite the folds computation logic from scratch so it should be much more faster. This will hopefully be integrated until 4.2 feature freeze. Checking in HTMLFoldManager.java; /cvs/html/editor/src/org/netbeans/modules/html/editor/folding/HTMLFoldManager.java,v <-- HTMLFoldManager.java new revision: 1.20; previous revision: 1.19 done
Marku - just curious, why did you move the issue to editor? I thought this was webapps-specific.
Hereby I confirm that it is now possible to work with IDE once the scan starts, type in editor, switch tabs etc. However, as Marek pointed out it takes significant amount of time to finish the computation. Verified as partially fixed in development build #200506031800 of NetBeans 4.2.
RequestProcessor gives you simpler API to achieve what you have done in http://html.netbeans.org/source/browse/html/editor/src/org/netbeans/modules/html/editor/folding/HTMLFoldManager.java?r1=1.19&r2=1.20 Do you really want to use java.util.TimerTask? These nested inner classes look awfull ;-)
To roman strobl: The reason why I reassigned the issue to the editor module has already been described in the text. Just for your comfort: "The problem seems not to have a trivial solution so a quite workaround fix can be to not to call the findMatchingBlock method after each typed character, but wait for a time, e.g. 500ms. This has to be done on the editor module side => reassigning." However, as I have also already mentioned, I am rewriting the folding manager for JSPs and HTMLs to 4.2 so the algorithm will be more effective and moreover the changes in the document will be reflected after a short pause after the user stops writing so the mechanism described in the paragraph above will be implemented on the web side. reassigning back.
*** Issue 61290 has been marked as a duplicate of this issue. ***
*** Issue 62226 has been marked as a duplicate of this issue. ***
fixed. The code responsible for document parsing and folds update has been entirely reewritten so now it is even more effective and faster. I have changed the behaviour of the folding a little: Now, when a user stops writing and the folding timeout (1000ms by default) elapses the parsing of the document starts. Even the parsing is not much more faster for a really huge and deeply structured documents it can take a few seconds. So if the user touches the file in the time of parsing the parsing is cancelled and restarted after next 1second again. This prevents the document update to be slowed down by the folding thread (mostly since on linuxes the threading priority doesn't matter much). Feel free to add your comments or problems using the folding. Checking in lib/src/org/netbeans/editor/ext/html/HTMLSyntaxSupport.java; /cvs/html/editor/lib/src/org/netbeans/editor/ext/html/HTMLSyntaxSupport.java,v <-- HTMLSyntaxSupport.java new revision: 1.16; previous revision: 1.15 done Checking in lib/src/org/netbeans/editor/ext/html/SyntaxElement.java; /cvs/html/editor/lib/src/org/netbeans/editor/ext/html/SyntaxElement.java,v <-- SyntaxElement.java new revision: 1.4; previous revision: 1.3 done Checking in src/org/netbeans/modules/html/editor/folding/HTMLFoldManager.java; /cvs/html/editor/src/org/netbeans/modules/html/editor/folding/HTMLFoldManager.java,v <-- HTMLFoldManager.java new revision: 1.21; previous revision: 1.20 done
a correction: ...Even the parsing is *NOW* much more faster for a real huge documents...
The folding is super fast now. Thanks for the great improvement. Verified in development build #200508311800 of NetBeans 4.2. However, the similar problem occurs because of tag matching feature but I will file separate issue for it.