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

[Stefan Monnier]

>> Can you try the patch below (for the emacs-24 branch), which tries to
>> make the existing cache in find_defun_start do something useful in the
>> case where find_defun_start returns BEGV?
> [ patch snipped ]
> I'm not sure what I'm meant to see,

An improvement in performance.

> but it has made no perceptible difference to the "slow" invocation of
> scan-lists.  In particular, that invocation took 0.7196781635284424
> seconds with the patch, which is "exactly" (near enough) what it
> took before.

Oh well.  What he patch does (or should do, at least) is that after
a "full scan from BOB", it remembers the last top-level open paren seen,
so that if the next back_comment's lossage happens in that same area, we
only rescan from that open paren rather than from BOB.

If it makes no measurable difference for your case, I see two explanations:
- a bug in the patch makes it do something else than what I wanted.
- lossage rarely happens more than "once per top-level paren", so the
  cache is almost never re-used anyway.

But since in your case it's a single scan-lists call that's slow and
that call only skips one single "sexp", the second explanation seems
wrong: you do see several occurrences of lossage (which together cause
the slowdown) and yet this is all within the same top-level paren.


        Stefan