unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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 --]

  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).