From: Jason Rohrer <jasonrohrer@fastmail.fm>
To: emacs-devel@gnu.org
Cc: emacs-devel@gnu.org
Subject: Re: C++-mode indenting performance depends on length of previous function?
Date: Sun, 01 Jul 2018 11:26:51 -0700 [thread overview]
Message-ID: <1530469611.421476.1426473800.499BD119@webmail.messagingengine.com> (raw)
In-Reply-To: <20180630194703.GD6816@ACM>
Confirmed that it is fixed in 26.1
Thanks!
Jason
On Sat, Jun 30, 2018, at 12:47 PM, Alan Mackenzie wrote:
> Hello, Jason.
>
> Thanks for the report. Thanks even more for making your source file so
> easily available, thus making it very easy for me to try things out.
>
> On Fri, Jun 29, 2018 at 08:20:51 -0700, Jason Rohrer wrote:
> > Tested in Emacs 23, 24, and 25. Same behavior with or without
> > font-lock-mode, and linum-mode is off.
>
> I think the problem is fixed in Emacs 26.1. This was released a little
> over a month ago.
>
> > I have a 6000-line C++ function with a bunch of internal nesting. I
> > would expect auto-indenting to be a bit slow inside this function, but
> > it turns out that it mostly is not slow, especially inside sub-blocks
> > of the giant function (inside the top-level block, it is a bit slow).
>
> I did an hg bisection on the CC Mode sources, and the git commit which
> seems to have serendipitously fixed the bug is:
>
> commit 59d07875df9d44568d93a7517853e6a5ccaf1e5b
> Author: Alan Mackenzie <acm@muc.de>
> Date: Sat Jul 1 15:43:07 2017 +0000
>
> Make C++ digit separators work. Amend the handling of single quotes
> generally
>
> > However, I'm seeing enormous slow-down when creating sub-blocks inside
> > the NEXT function, even if it is a short function. Both functions are
> > top-level blocks with 0-indent, but it seems like the auto-indent and
> > auto-bracket stuff is scanning the previous function for some reason.
> > And, unlike the good performance inside sub-blocks of the huge
> > function, I'm seeing slow performance in sub-blocks and sub-sub-blocks
> > of the next function. Nesting doesn't seem to change anything... It
> > must still be scanning the previous function block entirely for some
> > reason. If I put a tiny dummy function in between, the dummy function
> > is slow to edit, but the next function is fast again.
>
> I saw the slowness too, on Emacs 25.3. On my machine (which isn't by
> any means slow) there were pauses of, perhaps 0.5s when CC Mode had to
> indent things, in your tiny "workaround" function.
>
> Again, could you please try out Emacs 26.1
>
> [ .... ]
>
> > The live code in question is here:
>
> > https://github.com/jasonrohrer/OneLife/blob/master/gameSource/LivingLifePage.cpp
>
> :-)
>
> > Grep for "dummyFunctionA" and then try adding some new blocks inside
> > that function. Since it's the function after the gigantic ::step
> > function, editing it is slow. But the next function, ::makeActive, is
> > fast to edit.
>
> > Leaving dummyFunctionA in place is my current work-around. Otherwise,
> > makeActive is simply too slow/frustrating to edit.
>
>
>
> > (And before you tell me to re-factor the big function, I have my
> > reasons---it's a game loop---and "emacs can't handle it" shouldn't be
> > a driving reason to re-factor.)
>
> As maintainer of CC Mode, I've seen far worse (like a 6,000 line long
> macro). :-(
>
> > Anyone know what's going on here?
>
> > Why does the previous top-level block matter? Why doesn't it stop
> > scanning backward when it hits the beginning of the current top-level
> > block?
>
> I'm speculating, but sometimes it matters whether or not a brace pair is
> at the top level, particularly in such a complicated language as C++.
> With a long function this can take a long time to determine.
>
> Yet again, would you please see if you agree with me that the bug has
> been fixed in Emacs 26.1. If there are still unacceptable pauses, I'll
> take a more detailed look at the problem. Thanks!
>
> > Jason
>
> --
> Alan Mackenzie (Nuremberg, Germany).
prev parent reply other threads:[~2018-07-01 18:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-29 15:20 C++-mode indenting performance depends on length of previous function? Jason Rohrer
2018-06-30 19:47 ` Alan Mackenzie
2018-07-01 18:26 ` Jason Rohrer [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1530469611.421476.1426473800.499BD119@webmail.messagingengine.com \
--to=jasonrohrer@fastmail.fm \
--cc=emacs-devel@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.