It wasn’t a string, it was a single line function call. Very simple code. Like: Foo(); Chris On Sat, Dec 8, 2018 at 12:40 Alan Mackenzie wrote: > Hello, Chris. > > In article you wrote: > > > Hi, I recently upgraded from 25.3_1 to to 26.1 on Windows 7 x64 and I've > > noticed a very large performance regression on yanks in C++ mode buffers > > (it feels slower in many other operations as well, but I actually > > measured yank with the profiler). This happens even starting with with > > emacs -Q. > > > If I start emacs and visit a moderately large cpp file (18k LOC), and go > > to the same place in the middle of the file in both versions of emacs, > > then kill and yank the current line, the performance on 26.1 is easily > > 10x worse...the yank is instant in 25.3_1 and takes literally almost a > > second on 26.1 sometimes. I decided to test this with a profiler run, > > so I went to the same line in both, killed the line, and evaled this: > > > (progn (profiler-start 'cpu) (yank) (profiler-report) (profiler-stop)) > > > Here are the results: > > > 25.3_1: > > > - ... 1 100% > > Automatic GC 1 100% > > > > 26.1: > > - command-execute 14 100% > > - call-interactively 14 100% > > - funcall-interactively 14 100% > > - eval-expression 14 100% > > - eval 14 100% > > - progn 14 100% > > - yank 14 100% > > - insert-for-yank 14 100% > > - insert-for-yank-1 14 100% > > - c-after-change 13 92% > > - mapc 13 92% > > - # 13 92% > > - c-after-change-re-mark-raw-strings 6 42% > > - c-in-literal 3 21% > > - c-state-semi-pp-to-literal 3 21% > > c-parse-ps-state-below 3 21% > > - c-restore-<>-properties 4 28% > > c-syntactic-re-search-forward 4 28% > > c-neutralize-syntax-in-CPP 3 21% > > - remove-yank-excluded-properties 1 7% > > - remove-list-of-text-properties 1 7% > > - c-after-change 1 7% > > - c-before-change 1 7% > > - mapc 1 7% > > - # 1 7% > > c-depropertize-CPP 1 7% > > - ... 0 0% > > Automatic GC 0 0% > > What is this line that you kill, then yank? The profiler report > suggests that it has something to do with raw strings, and I wouldn't be > at all surprised if the line contains the opening delimiter or closing > delimiter of quite a big raw string. > > > I'm going to try the older cc-mode with the newer emacs and see if that > > fixes it, but I figured I'd report this bug now in case you haven't > > gotten other reports yet. > > There was no raw string handling at all in Emacs 25.3, so it is not > surprising that CC Mode is much faster, there. When a raw string is > started or terminated, CC Mode needs to check, potentially, the rest of > the buffer for characters which need "text properties" changing on them. > This can be time consuming. > > However, a change to a line in the inside of a raw string shouldn't be > slow, and if it is, that's a bug. > > > Thanks, > > Chris > > > > In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32) > > of 2018-05-30 built on CIRROCUMULUS > > Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea > > Windowing system distributor 'Microsoft Corp.', version 6.1.7601 > > Recent messages: > > For information about GNU Emacs and the GNU system, type C-h C-a. > > spyparty_ui.cpp has auto save data; consider M-x recover-this-file > > Mark saved where search started > > Mark set > > Quit > > CPU profiler started > > Mark set > > CPU profiler stopped > > "CPU profiler stopped" > > C-; is undefined > > Quit [3 times] > > Configured using: > > 'configure --without-dbus --host=x86_64-w64-mingw32 > > --without-compress-install 'CFLAGS=-O2 -static -g3'' > > -- > Alan Mackenzie (Nuremberg, Germany). > >