From: Chris Hecker <checker@d6.com>
To: Alan Mackenzie <acm@muc.de>
Cc: 33670@debbugs.gnu.org
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 [thread overview]
Message-ID: <CAOdMLc1da--htqCC2+k4qfQDkbOB=SFhp=_nPeyeaTi67gMCug@mail.gmail.com> (raw)
In-Reply-To: <20181208204036.61878.qmail@mail.muc.de>
[-- Attachment #1: Type: text/plain, Size: 4834 bytes --]
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 <acm@muc.de> wrote:
> 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).
>
>
[-- Attachment #2: Type: text/html, Size: 6429 bytes --]
next prev parent reply other threads:[~2018-12-08 21:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-08 2:42 bug#33670: 26.1; very large c++-mode yank performance regression 25.3_1-x86_64 -> 26.1-x86_64 Chris Hecker
2018-12-08 2:56 ` bug#33670: adding some info to my yank perf regression Chris Hecker
2018-12-08 7:49 ` bug#33670: 26.1; very large c++-mode yank performance regression 25.3_1-x86_64 -> 26.1-x86_64 Eli Zaretskii
[not found] ` <mailman.5359.1544236991.1284.bug-gnu-emacs@gnu.org>
2018-12-08 20:40 ` Alan Mackenzie
2018-12-08 21:31 ` Chris Hecker [this message]
2018-12-09 12:01 ` Alan Mackenzie
2018-12-09 17:57 ` Chris Hecker
2018-12-09 18:26 ` Alan Mackenzie
2022-01-29 15:20 ` Lars Ingebrigtsen
2022-01-29 16:35 ` Alan Mackenzie
2022-02-28 9:53 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOdMLc1da--htqCC2+k4qfQDkbOB=SFhp=_nPeyeaTi67gMCug@mail.gmail.com' \
--to=checker@d6.com \
--cc=33670@debbugs.gnu.org \
--cc=acm@muc.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).