Edit simple substitution too slow

[paurea]

wc xxx.tex
1213 8071 52355 xxx.tex
I
Edit , s/textit/emph/g
and it takes 20-30 seconds, which in p9p acme is instantaneous.
I am using edwood integrated in p9p as it comes just cloning
the git.

[fhs]

Looks like it's spending most of the time trying to apply the edit logs.

$ go tool pprof http://localhost:1994/debug/pprof/profile?seconds=30
Fetching profile over HTTP from http://localhost:1994/debug/pprof/profile?seconds=30
Saved profile in /home/fhs/pprof/pprof.edwood.samples.cpu.010.pb.gz
File: edwood
Type: cpu
Time: Apr 15, 2020 at 3:09pm (EDT)
Duration: 30s, Total samples = 360ms ( 1.20%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top -cum
Showing nodes accounting for 20ms, 5.56% of 360ms total
Showing top 10 nodes out of 94
      flat  flat%   sum%        cum   cum%
         0     0%     0%      220ms 61.11%  main.(*Elog).Apply
         0     0%     0%      220ms 61.11%  main.(*Row).AllWindows
         0     0%     0%      220ms 61.11%  main.MovedMouse
         0     0%     0%      220ms 61.11%  main.allupdate
         0     0%     0%      220ms 61.11%  main.edit
         0     0%     0%      220ms 61.11%  main.editcmd
         0     0%     0%      220ms 61.11%  main.execute
         0     0%     0%      220ms 61.11%  main.mousethread
         0     0%     0%      210ms 58.33%  github.com/rjkroege/edwood/internal/frame.(*frameimpl).DrawSel
      20ms  5.56%  5.56%      210ms 58.33%  github.com/rjkroege/edwood/internal/frame.(*frameimpl).Drawsel0

I'm using a file generated with:

yes '\textit This is a sentence that has just enough characters.' | sed 1213q > /tmp/xxx.tex

[rjkroege]

Not expected. I'll look into it.

[paurea]

This still happens. I have been testing it and it seems like hiding the window makes it faster, so I suspect some problem
with redrawing.

[paurea]

This is in Linux (in case it matters).

[rjkroege]

I haven't fixed this yet. Sorry.

[paul-lalonde]

I'm guessing this is because our buffer implementation is naive. We have to fix that before edwood is usable for any larger documents.

[rjkroege]

In #414, I added a benchmark to compare the performance of s and x commands.

BenchmarkLargeEditTargets10/edit_xPerf-10         	   53540	     22609 ns/op
BenchmarkLargeEditTargets10/edit_sPerf-10         	   41942	     28697 ns/op
BenchmarkLargeEditTargets109/edit_xPerf-10        	    7087	    160037 ns/op
BenchmarkLargeEditTargets109/edit_sPerf-10        	    3834	    298370 ns/op
BenchmarkLargeEditTargets1000/edit_xPerf-10       	     189	   6255238 ns/op
BenchmarkLargeEditTargets1000/edit_sPerf-10       	      79	  12831308 ns/op
BenchmarkLargeEditTargets10000/edit_xPerf-10      	       3	 427634153 ns/op
BenchmarkLargeEditTargets10000/edit_sPerf-10      	       2	 814397124 ns/op

A few issues are apparent from profiling the benchmark:

• s_cmd is about twice as slow. This is because s_cmd replicates the buffer on each match.
• Both x_cmd and s_cmd are much slower than desirable because of the text buffer implementation. (Fixing that is the topic of Idiomatic text buffers #97)
• Much of the benefit of completing Idiomatic text buffers #97 for regex operations require switching to a streaming regex API.

The 2-times performance difference seen in the benchmark is not sufficient to explain the performance difference while operating interactively. As noted by @fhs, this is because I (foolishly) removed what seemed like an unnecessary optimization when converting Acme'slibframe's implementation to frame.(*frameimpl).DrawSel

So: three primary action items ongoing:

• finish Idiomatic text buffers #97
• fix selection flicker #56 to reduce the time spent updating the selection
• convert the regex implementation to a streaming interface.

[rjkroege]

Reminder for @rjkroege: Fixing-slow-s-op.md are my notes for work needed for a streaming regex interface.