|
| From: | Chris Hecker |
| Subject: | bug#33670: 26.1; very large c++-mode yank performance regression 25.3_1-x86_64 -> 26.1-x86_64 |
| Date: | Sat, 8 Dec 2018 13:31:42 -0800 |
Hello, Chris.
In article <mailman.5359.1544236991.1284.bug-gnu-emacs@gnu.org> 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%
> - #<compiled 0x9dcce1> 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%
> - #<compiled 0xfcb439> 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).
| [Prev in Thread] | Current Thread | [Next in Thread] |