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

[Alan Mackenzie]

Hi, Stefan.

On Fri, Jun 27, 2014 at 06:54:55PM -0400, Stefan Monnier wrote:
> >> Could scan-lists be exhausting some sort of resource in this particular
> >> invocation which needs ~0.7s to replenish?  Or something like that?
> > Or a GC call or something like that?  Can't think of any reason why that
> > could happen, no.

> One way to figure it out is to change your code such that scan-lists is
> always called twice in a row.  If the time spend is the same both time,
> then it's definitely not some sort of resources exhaustion that just
> happens to slow down this one particular call.

Yes, the second call takes as long as the first call.

One thing that did make a big difference was binding
parse-sexp-ignore-comments to nil around a call to scan-lists.  My two
calls to (scan-lists 947171 -1 1) give these results:

parse-sexp-ignore-comments |  end position             time
---------------------------------------------------------------------
           t               |     919215         0.6976802349090576
          nil              |     899080         0.0021085739135742188

So, although with parse-..-comments nil, the distance traversed was
greater, the time taken was a factor ~300 less.  This suggests that
comments have something to do with the problem.

parse_sexp_ignore_comments is only tested twice in scan_lists.  The first
time, it is only setting up syntax table variables and suchlike after
having half-detected a comment closer.  The second time, back_comment
gets called.  It seems likely the problem is in back_comment.

AH!!!!!  GOT IT!!!!  What causes the slowdown is binding
open-paren-in-column-0-is-defun-start to nil around the scan-lists.  In
CC Mode's "engine" parts, that variable is bound to nil.  There are good
reasons for this (which I can't precisely recall just at the moment).

In CC Mode, "'" has string syntax.  So any C comment with an odd number
of apostrophes looks, to back_comment, like it has an "unbalanced string",
and the code ends up at label lossage: in back_comment.  Here
find_defun_start is called, and this returns BOB when open-paren-..-0 is
nil.  From here (BOB) the code scans forward to check this putative
"unbalanced string".  It's a long way from BOB to ~900k, hence the
sluggishness.

Where do we go from here?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).