#420 Performance optimisation for search&replace all

closed-rejected
None
5
2012-05-18
2012-05-18
No

Attached are two files:
1.) Text file to reproduce the current really slow search&replace all functionality
2.) The first performance patch, that improves the situation a bit and makes the search complete in more acceptable time

To reproduce the behaviour, search for "," and replace with ", " (note the extra space).

A nice bug was the value of the property "buffer.elasticTabstops=false " (spot the extra space) which resulted in a unexpected behaviour in JEditBuffer.getBooleanProperty(), and which is called quite often for the search&replace all case for the "elasticTabstops" property.

Several other optimisations that I found in the VisualVM profiler are included.

Discussion

  • Jarek Czekalski

    Jarek Czekalski - 2012-05-18

    Thomas, what performance gain (in numbers) did you achieve?

     
  • Thomas Meyer

    Thomas Meyer - 2012-05-18

    Hi, just try for yourself with attached test file! Unzip the file and search for "," and replace all with occurrences ", " (note the extra space). In current code I killed jEdit after 15 minutes or so, with this patch applied it finishes in about 2-3 minutes.

     
  • Thomas Meyer

    Thomas Meyer - 2012-05-18

    save storage in the UndoManager for equal Strings (triggered by mass remove() for save&replace all)

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-05-18

    Thanks for giving the numbers. Although I am suprise you work on performance without taking measurements. 2-3 minutes and forever are only impressions, not measurements. I have observed 60% performance gain, but it is achieved with a loss of functionality.

    1. Gutter: you forgot to update the lineNumberWidth
    2. setDirty - notice that you made some code unreachable, and thus md5 checking stopped working
    3. Vector vs ArrayList - don't do such changes without analyzing whether synchronization is not necessary. If you do the analyze, attach it.

    When I noticed that your performance patch was also very time efficient considering your time, I stopped reviewing the rest. Think of the reviewers time and the problems we may get from applying incorrect patches, broking current functionality.

    So I suggest: do only a single change for a single patch entry. For example only gutter change. Take measurement. Submit the change only if it visibly improves performance. Unnoticeable performance gain is not worth code complication. And maybe it's not worth time the reviewer has to spend on analyzing it.

    The gutter change is good. If you correct it and resubmit, I will surely apply it. I attach a benchmarking macro. I'm disappointed with the variability of results I get from the macro. It gives measerus from 8 to 10 ms per line. But an average may be taken and it's enough for detecting noticeable improvements.

    Again: undo manager patch needs another bug tracker entry and a description. And please review it to avoid mistakes like in this one. Also whitespace imperfections should be caught by you before submission.

    This entry is rejected. Single patches are welcome. Preferrably with measurements. I hope you'll not get discouraged with that.

    Tiny patches are easier to handle. I may analyze a small patch and quickly say: ok, let's have it. If a dev sees a complex patch, he may give up. I have to work now on a bug that was introduced by a patch. When we noticed the bug, the submitter was no longer available. So please understand our safety measures.

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-05-18
    • labels: 826387 -->
    • assigned_to: nobody --> jarekczek
    • status: open --> closed-rejected
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks