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

[Jason Rohrer <jasonrohrer@fastmail.fm>]

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