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 20439 - Very slow <enter> in editor
Summary: Very slow <enter> in editor
Status: CLOSED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Text (show other bugs)
Version: 3.x
Hardware: Sun Solaris
: P2 blocker (vote)
Assignee: Peter Zavadsky
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2002-02-11 16:02 UTC by Petr Nejedly
Modified: 2008-12-23 13:35 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Thread dump during the pause, only relevant thread (3.31 KB, text/plain)
2002-02-11 16:24 UTC, Petr Nejedly
Details
Diff of patch+regression fix for orion_fcs branch (16.87 KB, patch)
2002-03-20 14:51 UTC, Peter Zavadsky
Details | Diff
Patch (put in orion_fcs lib/patches dir) to try out. (48.59 KB, application/zip)
2002-03-20 14:57 UTC, Peter Zavadsky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Nejedly 2002-02-11 16:02:10 UTC
While editing large documents, inserting line break is slow at the beginning of
the document. The problem seems to lay in DocumentLine.equals()
which is too slow in the implementation internals.
See the attached StackTrace.

Reassign to openide/text if applicable
Comment 1 Petr Nejedly 2002-02-11 16:24:17 UTC
Created attachment 4656 [details]
Thread dump during the pause, only relevant thread
Comment 2 Petr Nejedly 2002-02-11 17:22:04 UTC
If a break is entered at the beggining of a file, all (N) lines
are moved, for all such lines a lineMove is fired which causes
comparison of all the lines with *all* registered lines (M) in the
same document (because all the DocumentLines from a single document
have the same hashCode()), i.e. NxM*equals().
During the subsequent equals() calls, each of the M registered lines
is asked for their lineNumber which is computed by a complex logic
in both openide/text and editor N times.

Now the raw numbers: For a 1000-line file and a standard M=1, it is
hardly noticeable. For a 1000-line file unsucessfully compiled
with ~30 error annotations (e.g. a wrong closing brace), it takes
about 1.5s to insert a line break on my machine.
We've got reports with way longer times.
Comment 3 Petr Nejedly 2002-02-12 09:56:18 UTC
cc:ing Peter, owner of openide/text
Comment 4 Petr Nejedly 2002-02-18 13:44:59 UTC
It may be the best to not use LineListener at all and let the Line.Set
listen on the Document itself.
Comment 5 Miloslav Metelka 2002-02-18 17:12:26 UTC
Although that will probably not help too much for elimination of this
issue I would like to switch to have permanent LineElements in 3.4.
The editor currently uses SyntaxMarks to store both the lexer info and
the line number. The syntax marks are constructed roughly at every
100th character (rouhly one mark per 5 lines). The line elements are
created lazily on demand.
 When we move to use the lexer module the syntax marks will no longer
be used so the only sense would be the line orientation. Although the
editor has specialized methods to handle line-oriented operations all
the "external" modules use the Swing API to get rid of dependency on
the editor. The typical scenario of use is I guess the following:
 line-root-element.find-line-element-index(position.getOffset());
This leads to use of the binary search to find the right line element
for the given offset. This will not be improved even in the new
implementation. What can be improved is the fact that with the current
implementation there is a cache for holding starting and ending offset
of the particular line. The line boundaries are computed when the line
is loaded into the cache. Normally about 98% of requests hits the
cache but if the requests come from the different locations in the
document the cache is not efficient enough.Altough the permanent line
elements will use more memory the line boundaries will be known from
the elements directly so there should be some performance improvement
by using this approach.
Comment 6 Peter Zavadsky 2002-02-19 15:45:48 UTC
Fixed in [main-trunk]

Fix:
openide/../text/CloneableEditorSupport.java [1.54]
                DocumentLine.java [1.43]
                EditorSupportLineSet.java [1.29]
                Line.java [1.19]
                LineListener.java [1.9]

Please revise the fix, if you find a time. Thanks.
Comment 7 Petr Nejedly 2002-02-19 16:05:39 UTC
Great, way better
Comment 8 Peter Zavadsky 2002-03-20 14:29:22 UTC
There was a regression by the above fix, see #21086.
Comment 9 Peter Zavadsky 2002-03-20 14:51:38 UTC
Created attachment 5114 [details]
Diff of patch+regression fix for orion_fcs branch
Comment 10 Peter Zavadsky 2002-03-20 14:57:02 UTC
Created attachment 5115 [details]
Patch (put in orion_fcs lib/patches dir) to try out.
Comment 11 Peter Zavadsky 2002-03-20 14:59:06 UTC
Please, review and approve for [orion_fcs] branch integration.
Comment 12 Jan Chalupa 2002-03-21 11:24:06 UTC
Approved.
Comment 13 Petr Jiricka 2002-03-21 13:28:38 UTC
Approved.
Comment 14 Quality Engineering 2003-07-01 16:39:33 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.