GNU bug report logs - #16526
24.3.50; scroll-conservatively & c-mode regression

Previous Next

Full log

Message #252 received at 16526 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 16526 <at> debbugs.gnu.org
Subject: Re: bug#16526: 24.3.50; scroll-conservatively & c-mode regression
Date: Fri, 04 Jul 2014 15:11:24 -0400

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.