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 219032 - LowPerformance took 105891 ms.
Summary: LowPerformance took 105891 ms.
Status: RESOLVED INVALID
Alias: None
Product: xml
Classification: Unclassified
Component: Text-Edit (show other bugs)
Version: 7.2
Hardware: All All
: P3 normal (vote)
Assignee: Svata Dedic
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2012-09-26 03:38 UTC by Exceptions Reporter
Modified: 2012-10-29 10:26 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 161734


Attachments
nps snapshot (1.26 MB, application/nps)
2012-09-26 03:39 UTC, Exceptions Reporter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Exceptions Reporter 2012-09-26 03:38:44 UTC
Build: NetBeans IDE 7.2 (Build 201207171143)
VM: OpenJDK Client VM, 14.0-b16, OpenJDK Runtime Environment, 1.6.0_18-b18
OS: Linux

User Comments:
leopard2av: formatting a ~2860 lines xml file

GUEST: Batch search&replace on 3.3M text file; making snapshot

aldobrucale: undi in an xml file (arch.xml)



Maximum slowness yet reported was 105891 ms, average is 24220
Comment 1 Exceptions Reporter 2012-09-26 03:39:07 UTC
Created attachment 124919 [details]
nps snapshot
Comment 2 Milutin Kristofic 2012-09-26 11:04:54 UTC
Replace all on 2000 matches on big xml file which was still parsing.

For evaluate to xml editor.
Comment 3 Svata Dedic 2012-10-23 06:33:59 UTC
I can see numerous calls to remove() and insertString() with the associated processing: scheduling reparse, update highlights, ... Lot of time took javax.swing.Timer.restart(), with reported contention on TimerQueue ? The statistics may be damaged, since even RP.Task.notifyRunning() which does nothing except lock & notifyAll takes significant time.
Comment 4 Svata Dedic 2012-10-29 10:26:07 UTC
Seems as rather some screwed snapshot. I tried to replace 26k matches in a 53k line document, no suspicious behaviour. Note that most of the time in the replace  loop was taken by the document modification operations which have to happen under a write lock: if the replace loop was offloaded from AWT thread elsewhere, the IDE would freeze or we would need to display some 'placeholder' instead of the document, since document contents would not be available during the replace computation for reading (it is write-locked almost all the time)