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

[Jason Rohrer <jasonrohrer@fastmail.fm>]

Tested in Emacs 23, 24, and 25.  Same behavior with or without font-lock-mode, and linum-mode is off.

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

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.

void longComplicatedFunction() {
    // imagine 6000 lines here
}

void anotherShorterFunction() {
    // very slow to edit this
}



But with the dummy function in between, I see:

void longComplicatedFunction() {
    // imagine 6000 lines here
}

void dummyFunction() {
    // very slow to edit this, now
}

void anotherShorterFunction() {
    // fast editing, back to normal
}


Profiler shows that electric-brace and electric-paren are to blame:

- command-execute                                               18219  99%
 - call-interactively                                           18217  99%
  + c-electric-brace                                            11417  62%
  + c-electric-paren                                             2562  14%
  + c-indent-line-or-region                                      2223  12%
  + newline                                                      1927  10%
  + self-insert-command                                            42   0%
  + minibuffer-complete                                            18   0%
  + execute-extended-command                                        9   0%
  + c-electric-backspace                                            7   0%
  + byte-code                                                       7   0%
  + previous-line                                                   5   0%
+ ...                                                              21   0%
+ redisplay_internal (C function)                                   4   0%
+ timer-event-handler                                               2   0%


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



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?


Jason