Re: C++-mode indenting performance depends on length of previous function?

[Alan Mackenzie]

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 <address@hidden>
    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).