GNU bug report logs - #33670
26.1; very large c++-mode yank performance regression 25.3_1-x86_64 -> 26.1-x86_64

Previous Next

Full log

View this message in rfc822 format

From: Chris Hecker <checker <at> d6.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 33670 <at> 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

[Message part 1 (text/plain, inline)]

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 <at> muc.de> wrote:

> Hello, Chris.
>
> In article <mailman.5359.1544236991.1284.bug-gnu-emacs <at> 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).
>
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.