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 157433 - Low performance and frozen UI for replace All in big documents
Summary: Low performance and frozen UI for replace All in big documents
Status: RESOLVED DUPLICATE of bug 214949
Alias: None
Product: editor
Classification: Unclassified
Component: Search (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: Milutin Kristofic
URL:
Keywords: PERFORMANCE
: 170301 184397 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-01-26 12:18 UTC by Vladimir Voskresensky
Modified: 2012-11-29 17:52 UTC (History)
5 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
javascript file as testcase for replace performance (46.35 KB, text/x-c)
2010-01-17 16:20 UTC, bht
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Voskresensky 2009-01-26 12:18:44 UTC
I have tried "Replace All" in a big document (300K lines) and it took a lot of time (not finished after 20 minutes) + 
frozen UI.
Taking several dumps shows[1] standing in one critical place org.netbeans.editor.DocumentContent.getText(int offset, int
length) where each time huge amount of data is copied to create new String object.
It is not needed in this particular case. Please, optimize algorithm with CharSequence reuse, instead of working with
new String objects.
Thanks,
Vladimir.

[1] hot spot:
"AWT-EventQueue-1" prio=3 tid=0x0bc44400 nid=0x1f runnable [0x69bff000..0x69bffc70]
   java.lang.Thread.State: RUNNABLE
        at org.netbeans.editor.DocumentContent.getText(DocumentContent.java:182)
        at org.netbeans.editor.DocumentContent$CharSequenceImpl.subSequence(DocumentContent.java:373)
        at org.netbeans.lib.editor.util.swing.DocumentUtilities.getText(DocumentUtilities.java:322)
        at org.netbeans.modules.editor.lib2.search.DocumentFinder.findReplaceImpl(DocumentFinder.java:232)
        at org.netbeans.modules.editor.lib2.search.DocumentFinder.findReplaceResult(DocumentFinder.java:312)
        at org.netbeans.modules.editor.lib2.search.EditorFindSupport.findReplaceInBlock(EditorFindSupport.java:589)
        at org.netbeans.modules.editor.lib2.search.EditorFindSupport.replaceAll(EditorFindSupport.java:772)
        at org.netbeans.editor.FindSupport.replaceAll(FindSupport.java:175)
        at org.netbeans.editor.ext.FindDialogSupport.actionPerformed(FindDialogSupport.java:373)
        at org.netbeans.core.windows.services.NbPresenter$ButtonListener.actionPerformed(NbPresenter.java:1267)
        at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
        at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
        at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
        at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
        at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
        at java.awt.Component.processMouseEvent(Component.java:6134)
        at javax.swing.JComponent.processMouseEvent(JComponent.java:3265)
        at java.awt.Component.processEvent(Component.java:5899)
        at java.awt.Container.processEvent(Container.java:2023)
        at java.awt.Component.dispatchEventImpl(Component.java:4501)
        at java.awt.Container.dispatchEventImpl(Container.java:2081)
        at java.awt.Component.dispatchEvent(Component.java:4331)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4301)
        at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3965)
        at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3895)
        at java.awt.Container.dispatchEventImpl(Container.java:2067)
        at java.awt.Window.dispatchEventImpl(Window.java:2458)
        at java.awt.Component.dispatchEvent(Component.java:4331)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
        at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:104)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Comment 1 Vitezslav Stejskal 2009-02-06 14:21:58 UTC
I fixed the CharSequence implementation, but the replace-all operation on 300K lines file may still take a long time.
The time depends on how many occurrences of the searched test there are in the document. I tried replacing text that was
on each line (ie. 300K occurrences) and the operation took too long to wait for (more than ~5min). I tried the same with
only ~10 occurrences and it took ~5 seconds. I also tried the same in 10K lines file with 10K occurrences of the
searched text and the operation finished in approx. 5 seconds.

I consider this good enough to mark this P3.

local changeset: a654b8de80a1
Comment 2 Vladimir Voskresensky 2009-02-06 17:27:28 UTC
We will check when changes are in trunk, but from your measurements seems, that speed is still slow.

Btw, just checked XEmacs with 300K file with 33K occurrences.
Full Replace: 2 sec
Undo: 2 sec

Do they have magic knowledge?
Comment 3 Quality Engineering 2009-02-09 20:30:56 UTC
Integrated into 'main-golden', will be available in build *200902091451* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/a654b8de80a1
User: Vita Stejskal <vstejskal@netbeans.org>
Log: #157433: use more efficient CharSequence implementation
Comment 4 Sergey Petrov 2009-04-14 09:44:29 UTC
I'm not sure time can be constant for any file size, how it was determined 300k file time isn't good enough? if time for
300k will be good(for example<5min), it always possible to find file with 600k lines and got similar "problem"(>5min).
I just tried to create 150K lines file, and after reopening editor says "FIle is bigger then 6M...". Also got several
outofmemory with this file, may be because it' 150K todos.

Is it still considered as valid issue?
Comment 5 Vladimir Voskresensky 2009-04-14 10:00:24 UTC
re: "how it was determined time isn't good enough?" 
- there is usually responsiveness criteria for feature to be useful:
Let's do operation in Emacs => spending 2 seconds (two seconds!) is considered to be acceptable responsiveness for most
users (may be some are still not satisfied). 
Doing the same thing in NB and waiting for minutes(!) is rather long time to claim that time is not acceptable, isn't it?
Comment 6 Sergey Petrov 2009-04-14 10:11:56 UTC
with 200K files of simple comments got waring with not enough memory to compile folder, and gt OutOfMemory on attempt to
replace 200K of the same entries with another. 
Comment 7 Sergey Petrov 2009-04-14 10:36:21 UTC
ok, even nb may not be the same as Emacs in functionality/perfomance, outofmemory seems to be an issue anyway.
Comment 8 bht 2010-01-17 16:20:07 UTC
Created attachment 93358 [details]
javascript file as testcase for replace performance

Testcase for regions.js
How to reproduce:

- Open the attached file regions.js in the editor.
  Please note this file has close to 50,000 characters in one line.
- Copy the value of var delimiter=""; to the clipboard.
  It is the special ASCII character "Field Delimiter"
- Highlight a single character "|" on line 1
- Menu|Edit|Replace
  Find What: |
  Replace With: (paste from clipboard)
  Check boxes checked: "Highlight Results", "Wrap Around", "Incremental Search"
- Press button "Replace All"

NetBeans locks up with 100% CPU. I can't do it, I have to use another editor.
Comment 9 Vitezslav Stejskal 2010-04-19 10:16:14 UTC
*** Bug 170301 has been marked as a duplicate of this bug. ***
Comment 10 Vitezslav Stejskal 2010-04-19 10:16:30 UTC
*** Bug 184397 has been marked as a duplicate of this bug. ***
Comment 11 David Strupl 2010-10-01 15:40:00 UTC
Any patches are more than welcomed for this issue. I am making it ENH and making it next (not for the upcoming release).
Comment 12 Milutin Kristofic 2012-11-29 17:52:23 UTC

*** This bug has been marked as a duplicate of bug 214949 ***