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.
When editing a rather large RHTML file, the editor becomes so slow that it is impossible to continue working. In particular, whenever one enters new text, the editor hangs for several seconds. My guess is, that some kind of completion routine takes the time.
Completion shouldn't be taking any time when you're just entering new text. Would you mind generating a thread dump (and attaching it here) ? http://wiki.netbeans.org/wiki/view/GenerateThreadDump That will show exactly where the problem is. Also, how large (in terms of character count or line count) is your rather large RHTML file? Does it contain any JavaScript or CSS? And is this using Beta1 or a daily build?
Created attachment 49300 [details] NetBeans Thread Dump
The RHTML file has 32000 chars (incl whitespace), mostly standard HTML with lots of tables for layout purposes (which is evil, I know, but CSS for forms is just as bad). There are is no JS or CSS in the file directly. The thread dump is from Beta 1 but I experienced the same problems with current daily builds. Googling I found this: http://www.ruby-forum.com/topic/124930 Maybe the guy has the same problem.
I can reproduce this myself; I took a couple of RHTML files and concatenated them - and editing a large file is unbearably slow. Parsing seems to happen asynchronously, but then the IDE freezes for several seconds. The attached thread dump (and I observed the same thing myself) shows that the problem is inside of the Schliemann code for creating Navigator items (which is done lazily from a JTree model, thus this happens on the AWT thread). The root problem is that the navigator code goes and computes the Line object for each and every navigator node - just so that it can use it if the user later clicks on the line to navigate to it! Computing a Line object is very expensive - it involves looking up the line number of a given editor offset, which itself involves iteration in the gap buffer. Since this is done for all the top level nodes on the first call into the tree model, this involves nested iteration. I don't think the navigator nodes should compute the Line objects for the unlikely case that they are clicked (on most edits they are not, and even when they are, only one out of the entire set). I think instead only the known offsets should be stored in the nodes, and on mouse clicks we go and compute the offsets instead. True, if you edit the buffer and then click on the navigator before it has updated, the offsets may be a few characters off, but that is true today as well for the column offset which is static. I'll attach a simple patch which does this, and which is a LOT faster for my testcase (an 800 line RHTML file). (Issue 115948 also seems to cause serious RHTML editing slowdown; I worked around that for timing purposes in my own workspace by returning null rather than throwing an exception from the languages manager, and then adding various language==null checks in the various clients of the LanguageManager.)
Created attachment 49332 [details] Proposed fix for LanguagesNavigator: compute Line objects only when needed
A note on the patch: I didn't stash the target offset with the navigator items since it seemed it could be derived by just looking at the node path (last element) but I may not understand how the AST nodes work. If that's wrong it could alternatively stash the offset along with the doc reference when creating the navigator nodes. (Also, it would probably be better to delay initialization of the Line.Set until strictly necessary as well, but I wanted to keep the patch small, and this only matters if the Line.Set isn't already used in other places in Schliemann already.)
fixed in trunk. Thanks for submitted patch. IDE:------------------------------------------------- IDE: [9/24/07 1:28 PM] Committing "LanguagesNavigator.java" started Checking in LanguagesNavigator.java; /cvs/languages/engine/src/org/netbeans/modules/languages/features/LanguagesNavigator.java,v <-- LanguagesNavigator.java new revision: 1.17; previous revision: 1.16 done IDE: [9/24/07 1:28 PM] Committing "LanguagesNavigator.java" finished