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.

Bug 116395 - Navigator is very slow
Summary: Navigator is very slow
Alias: None
Product: obsolete
Classification: Unclassified
Component: languages (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P2 blocker (vote)
Assignee: issues@obsolete
Depends on:
Reported: 2007-09-22 12:37 UTC by mgkaiser
Modified: 2007-09-24 12:33 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

NetBeans Thread Dump (15.74 KB, application/octet-stream)
2007-09-22 20:25 UTC, mgkaiser
Proposed fix for LanguagesNavigator: compute Line objects only when needed (3.33 KB, text/plain)
2007-09-23 23:30 UTC, Torbjorn Norbye

Note You need to log in before you can comment on or make changes to this bug.
Description mgkaiser 2007-09-22 12:37:57 UTC
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.
Comment 1 Torbjorn Norbye 2007-09-22 16:00:02 UTC
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) ?

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?
Comment 2 mgkaiser 2007-09-22 20:25:54 UTC
Created attachment 49300 [details]
NetBeans Thread Dump
Comment 3 mgkaiser 2007-09-22 20:32:48 UTC
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:
Maybe the guy has the same problem.

Comment 4 Torbjorn Norbye 2007-09-23 23:27:19 UTC
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.)
Comment 5 Torbjorn Norbye 2007-09-23 23:30:29 UTC
Created attachment 49332 [details]
Proposed fix for LanguagesNavigator: compute Line objects only when needed
Comment 6 Torbjorn Norbye 2007-09-23 23:33:54 UTC
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.)
Comment 7 Jan Jancura 2007-09-24 12:33:11 UTC
fixed in trunk.
Thanks for submitted patch.

IDE: [9/24/07 1:28 PM] Committing "" started
Checking in;
/cvs/languages/engine/src/org/netbeans/modules/languages/features/,v  <--
new revision: 1.17; previous revision: 1.16
IDE: [9/24/07 1:28 PM] Committing "" finished