GNU bug report logs -
#16526
24.3.50; scroll-conservatively & c-mode regression
Previous Next
Reported by: martin rudalics <rudalics <at> gmx.at>
Date: Thu, 23 Jan 2014 08:54:02 UTC
Severity: important
Found in version 24.3.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #159 received at 16526-done <at> debbugs.gnu.org (full text, mbox):
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 <at> gnu.org>
> > Cc: rudalics <at> gmx.at, 16526 <at> debbugs.gnu.org
> > > Date: Wed, 5 Feb 2014 23:00:01 +0000
> > > Cc: rudalics <at> gmx.at, 16526 <at> debbugs.gnu.org
> > > From: Alan Mackenzie <acm <at> 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).
This bug report was last modified 11 years and 35 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.