bug#16526: 24.3.50; scroll-conservatively & c-mode regression

[Alan Mackenzie]

Hi, Eli.

On Sun, Jun 22, 2014 at 07:49:29PM +0300, Eli Zaretskii wrote:
> > Date: Thu, 06 Feb 2014 08:01:32 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: rudalics@gmx.at, 16526@debbugs.gnu.org

> > > Date: Wed, 5 Feb 2014 23:00:01 +0000
> > > Cc: rudalics@gmx.at, 16526@debbugs.gnu.org
> > > From: Alan Mackenzie <acm@muc.de>

> > > > Do you need help in identifying what takes 11 sec in the unoptimized
> > > > build to traverse a few lines?

Just to recap what was taking 11 seconds.  With xdisp.c revision 116189
newly loaded into an emacs -Q, do (goto-char 948757).  This emacs was
built with CFLAGS='-O0 -g3' and --enable-checking='yes,glyphs'

Yes, I would like some help, please.

[ From this point on, all my timings are with reference to my normal
optimised build of Emacs 24.3 (though the version doesn't make any
difference). ]

I elp-instrument-package "c-" and elp-instrument-function "scan-lists".
After the (goto-char 948757), my elp-results looks like this (with blank
lines added for clarity):

c-font-lock-fontify-region                       6           1.12553871    
0.187589785
scan-lists                                       2359        0.9151535670  
0.0003879413
c-parse-state                                    200         0.8451750940  
0.0042258754
c-parse-state-1                                  200         0.7929608409  
0.0039648042
c-font-lock-enclosing-decls                      6           0.7164836050  
0.1194139341

c-append-lower-brace-pair-to-state-cache         4           0.7143309609  
0.1785827402
c-font-lock-declarations                         6           0.255113226   
0.0425188710
c-find-decl-spots                                6           0.255040271   
0.0425067118
c-backward-over-enum-header                      62          0.1797902729  
0.0028998431
c-font-lock-complex-decl-prepare                 6           0.0648537759  
0.0108089626

Clearly c-append-lower-brace-pair-to-state-cache is problematic.

I then timed each of the four calls of c-append-lower-...-cache.  Three
were rapid, one took 0.6977412700653076 seconds.  I then zeroed in on the
main loop (the only loop, really) and when I found it was hardly looping
at all (a mere four calls of scan-lists altogether).  I then timed _each_
individual call of scan-lists, and found that the call

    (scan-lists 947171 -1 1)

took 0.6962041854858398 seconds.  (947171 is just inside the closing
brace of syms_of_xdisp, and the result of the scan is 919215, the
function's opening brace.)

How come this scan-lists is taking 0.7 seconds?  When I call this from
M-: (let ((thyme (float-time))) (scan-lists 947171 -1 1) (- (float-time) thyme))
, I get 0.013844966888427734 seconds, 2% of the above figure.

It is true that in CC-Mode, that bit of the code is deeply nested inside
some macros which manipulate text properties.  But when I include these
in the manual call of scan-lists, they barely make any difference.

How can this one single scan-lists called from CC Mode be so slow, yet
the identical call from the minibuffer be 50 times as fast?  My
understanding is that scan-lists is a primitive operation, unaffected by
virtually any context (apart from specific things like
parse-sexp-ignore-comments and syntax-table text properties which are
meant to affect it).

I'm at a loss for ideas right now.  Suggestions would be most welcome.

-- 
Alan Mackenzie (Nuremberg, Germany).