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.
NetBeans IDE Dev (Build 070416) 1.6.0; Java HotSpot(TM) Client VM 1.6.0-b105 Linux version 2.6.16-1.2122_FC5 running on i386 Used big ide build Editing of html code with errors is very slow. There are appreciable delays after each scrolling of document or written character.
I cannot say it works in editor without errors because there is always some errors in this editor. It seems the delays become longer with time of editing.
could you please do a few threaddumps during the slowness and attach them to the issue? It will help to find out what causes the problem. Thanks.
Created attachment 41334 [details] a threaddump when ide did something in html editor
Created attachment 41337 [details] another one with some exception
Created attachment 41338 [details] out of memory in the state
this is very usefull, thanks!!!
It think it is stopper for m9. After the oome ide is dead for minutes.
Can you attach the file you use for testing this problem? I cannot reproduce. The stacktrace shows that the html parser which creates the embedding runs properly (at least I see a progress in the dumps) and the Schliemann parser resolves the generated parser items into an AST... Isn't the file huge??? Please attach it...
Created attachment 41345 [details] file
I cannot reproduce the problem, I tried to open and edit the document, but the parser/s runs just for a very short moment (the CPU load increases for about ~0,7sec) after a document modification. After the parsers finishes, the load is minimum and I can scroll without problems. Can you please verify on a latest build? I am closing the issue as WORKSFORME, please reopen if you can reproduce on latest build with new clean userdir. Thanks.
I can reproduce it very easily. Try to edit the file for a while. Usually 5 minutes is enough. Performance degrades to some critical state like OOME or a deadlock - I found in build NetBeans IDE Dev (Build 20070423-0650).
Created attachment 41425 [details] deadlock's threaddump
Can you also attach the output of the "jmap -histo <pid>" after OOME for the record, please?
I have found and fixed an issue which affects a CPU performance. Before the fix, if I pressed and held a key for a while in the document the CPU peformance increased to 100% for quite a long time. There used to be a problem with creating new String instancies of a parts of the editoted document in JspLexer.getPossibleTagName(). I have replaced it by using CharSequences, the perf. increased rapidly. Another problem I see when I edit the file is that the MyFirstDrawLayer.updateContext() method called from the DrawEngine when painting the document is very very slow -calls to FileSystems, then parses the obtained data, simply no caching at all. Once Hanz fixes this, the performance will IMO increase a lot. I have filled it as an issue #102175. "AWT-EventQueue-1" prio=1 tid=0x08242b80 nid=0x35df runnable [0x9ef6e000..0x9ef6f140] at java.lang.String.<init>(String.java:208) at java.lang.StringBuilder.toString(StringBuilder.java:431) at org.openide.filesystems.FileObject.getPath(FileObject.java:167) at org.openide.filesystems.MultiFileObject.getAttribute(MultiFileObject.java:673) at org.netbeans.modules.languages.features.ColorsManager.getBundleName(ColorsManager.java:352) at org.netbeans.modules.languages.features.ColorsManager.getColors(ColorsManager.java:62) at org.netbeans.modules.languages.features.MyFirstDrawLayer.updateContext(MyFirstDrawLayer.java:130) at org.netbeans.editor.DrawEngine.computeFragmentDisplayWidth(DrawEngine.java:470) at org.netbeans.editor.DrawEngine.drawCurrentTokenFragment(DrawEngine.java:783) at org.netbeans.editor.DrawEngine.drawCurrentToken(DrawEngine.java:880) at org.netbeans.editor.DrawEngine.draw(DrawEngine.java:1062) ..... As for the problems you described (OOM) I really cannot reproduce, I never see the row of HTML.clone() methods as is shown in your threaddumps. I'll keep trying...
> I have filled it as an issue #102175. Since this is a P1, shouldn't 102175 be a P1 as well?
Performance of editing is better now. I did not seen the OOME since the last occurence.
Created attachment 41699 [details] current threaddump
Eman confirms the editing is faster and he cannot reproduce the OOME. Closing the issue as fixed. As for the last threaddump, please file a separate issue with some steps to reproduce or at least an info what you did before and what happened then. Thanks.
verified