[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: C++-mode indenting performance depends on length of previous functio
Re: C++-mode indenting performance depends on length of previous function?
Sun, 01 Jul 2018 11:26:51 -0700
Confirmed that it is fixed in 26.1
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 <address@hidden>
> Date: Sat Jul 1 15:43:07 2017 +0000
> Make C++ digit separators work. Amend the handling of single quotes
> > 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 in Thread]
||[Next in Thread]|
- Re: C++-mode indenting performance depends on length of previous function?,
Jason Rohrer <=