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.
Summary: | [REGRESSION] High number of positions when editing java and C++ files | ||
---|---|---|---|
Product: | editor | Reporter: | Vladimir Voskresensky <vv159170> |
Component: | Painting & Printing | Assignee: | Miloslav Metelka <mmetelka> |
Status: | VERIFIED FIXED | ||
Severity: | normal | CC: | issues, juhrik, mmirilovic |
Priority: | P1 | Keywords: | PERFORMANCE, REGRESSION |
Version: | 7.0 | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 194570 |
Description
Vladimir Voskresensky
2011-01-20 14:56:18 UTC
MarkVector was not changed for ages (last change except license updates was 2007) so the only explanation is that there's unusually high number of marks to be handled (likely due to a high number of document position for that particular document). (In reply to comment #1) > MarkVector was not changed for ages (last change except license updates was > 2007) you are right, we faced it's slowness for several releases :-) > so the only explanation is that there's unusually high number of marks to > be handled (likely due to a high number of document position for that > particular document). so, it's worth to investigate the issue (why slow component is used 10 times more causing 10 times slower performance as a result). May be you can find a way to improve/replace this slow element? Hi Vladimir, I have a brand new DocumentContent ready that will feature Position instances sharing but I first need to get rid of the o.n.editor.Mark support so I will put it in after-7.0 release. Anyway I still believe that for some reason you have a high number of position objects (MarkVector.java:703 corresponds to mark array iterating) and so that the MarkVector itself is not the culprit so I mark the issue as invalid. If I'm wrong please reopen. I've added a dump of the mark count into BaseDocument.toStringDetail() for a quick check of how many marks are present at the moment. after discussion and some investigations we've decided to reopen it: ------- Vladimir, you're right - the position count is high for java too, in the meantime I've used the added markcount info and for 80-line java file it's 1104 marks which is pretty high. I'm now searching what's holding the positions. -------- Integrated into 'main-golden', will be available in build *201101270001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/e0d2f0fe39b7 User: Miloslav Metelka <mmetelka@netbeans.org> Log: #194527 - MarkVector is 700% slower comparing to 6.9.1 - Info about mark count added to BaseDocument.toStringDetail(). Mila, may be there are too much objects attached to the same position? Then you can use new version of WeakSet which has method putIfAbsent to share same object between all clients I have added position creation stack tracing and the number of positions is roughly 2.7x number of lines: 1 position per line is for a line element start position. 1 position per line is for a paragraph view's start. With the new document content the same position instance would be shared in this case. 0.7 position per-line corresponds to other structures like folds, annotations etc. Anyway during the reformat the view hierarchy updates are turned off. The view hierarchy is rebuilt after the reformat gets finished. http://hg.netbeans.org/jet-main/rev/5ca6146a126b http://hg.netbeans.org/jet-main/rev/64e6f65c2206 I'll now debug the individual inserts/removals done by the reformatter and the individual document listeners. Integrated into 'main-golden', will be available in build *201102010000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/5ca6146a126b User: Miloslav Metelka <mmetelka@netbeans.org> Log: #194527 - High number of positions when editing java and C++ files - added extra debugging; fixed missing read-lock in AnnotationView. Oops, at first look I have overlooked a missing break of the mark iteration loop in MarkVector.moveOffsetGap() but it obviously degrades performance, sorry for that. I have double-checked that there's no similar error across the sources but it should be fine since all other usages come from OffsetGapList where the moveOffsetGap() does not split below/above gap iteration so it's fine. Vladimir, thanks for finding this. http://hg.netbeans.org/jet-main/rev/f5a1a3394a44 let's nominate for 7.0, right? Ok, Vladimir, please verify that the fix works for you. Thanks. 8 minutes without fix on very fast machine... will check speed when http://hg.netbeans.org/jet-main/rev/f5a1a3394a44 is propagated into cnd-main Mila, works great! Now time is 90 secs on the same machine. Great work! Thanks, Vladimir. Based on the verification above I agree with integration to nb70. Integrated into 'main-golden', will be available in build *201103230400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/f5a1a3394a44 User: Miloslav Metelka <mmetelka@netbeans.org> Log: #194527 - High number of positions when editing java and C++ files - performance improvement of marks iteration loop. Integrated into release70: f5a1a3394a44 transplanted to e61447073489 Vladimir, could you please verify also in the latest 70 build? Thanks. verified in 7.0 |