D17441: tune editing actions for large number of small edits

[Christoph Cullmann]

cullmann added a comment.


  In D17441#373728 <https://phabricator.kde.org/D17441#373728>, @loh.tar wrote:
  
  > I have tried this one. Yes, works much more better! 
  >  Nice to see that my own (unloved) patch wake your interest to dig into that issue :-)
  
  
  :=) Nice that it helps a bit for the speed isue.
  
  > As usual understand I most of your talk here not really, and these perf protocols give me no light on the first sight. But thank you that you let me participate.
  
  perf helps you to easily see the hotspots.
  
  e.g. you run
  
  perf report --call-graph dwarf -F 333 kwrite the_test_file...
  
  do your actions there (here replace all).
  
  Afterwards (or if you want only partial trace, press once CTRL-C), you run for the flat profile
  
  perf report --max-stack 1024 --stdio -g none > report.txt
  
  Then you see directly which functions might need attentions.
  
  If e.g. a function takes 10% cumulative, 10% is spend in it and all stuff it calls.
  If you see there strange stuff, like e.g. the saveEditingPositons, that is a nice start for optimizations.
  
  perf report
  
  will allow to have some text ui, or use hotspot for graphical bliss. (or generate flamegraph svgs)
  
  > 
  > 
  > - Now, just find all of a char in that fat file is done very quickly
  > - Doing these tab->semicolon S&R still takes quite a while but works here. System monitor told 1.8G memory was eaten
  > 
  >   I think with this patch need KateSearchBar still some improvement. Like to give a hint that S&R is running and the possibility to abort. Would be good to add some test if a S&R may run out of memory. Not everyone has a lot of RAM available.
  > 
  >   Um, just a stupid question: Is there a need to do the S&R just as it is done currently? So far I understand that, is the only reason why that is so f**antastic slow caused by tons off calls which are intend to track a normal editing.
  > 
  >   Why not simple do the S&R on the raw file, make a diff, highlight the changes and we are done(?) I did the tab->semicolon S&R by sed, just for interest, and it takes 2-3 seconds :-/
  
  The thing is: is you do that this way, you loose all convenience.
  e.g. if the user has marks on lines, they will not move, if there are additional highlighings, they are lost, even if you just replace a few letters somewhere.
  All that overhead is there for a reason to have nifty features, if you want raw speed, yes, a script or plain command line tool like sed will always win.
  But I think we should try to shave of as much overhead as possible, without crippling the user experience.

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D17441

To: cullmann, dhaumann, #kate, loh.tar
Cc: anthonyfieroni, kwrite-devel, kde-frameworks-devel, hase, michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kwrite-devel/attachments/20181209/4e5bb136/attachment.html>