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

Previous Next

Full log

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

From: Alan Mackenzie <acm <at> muc.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 16526-done <at> debbugs.gnu.org
Subject: Re: bug#16526: 24.3.50; scroll-conservatively & c-mode regression
Date: Fri, 27 Jun 2014 20:34:16 +0000

Hi, Stefan.

Thanks for the reply.

On Wed, Jun 25, 2014 at 10:51:24PM -0400, Stefan Monnier wrote:
> > 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?

> Do the two return the same position?

They do, yes.

> The time taken by scan-lists is proportional to the "distance", so a
> 50x slowdown would not be surprising if it goes 50x further.

This is surely not the problem.  50x further would have taken point well
outside the bounds of the file to a negative offset.  Besides, I printed
out the end position (in both cases) with `message'.  That position was
of the opening brace of syms_of_xdisp.

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

> Another influence could be parse-sexp-lookup-properties, tho it
> definitely shouldn't account for more than a few percents.

parse-sexp-lookup-properties was set in both cases.  (CC Mode sets it
buffer locally in its initialisation.)

Could CC Mode's use of category text properties be causing this delay,
somehow?

Could scan-lists be exhausting some sort of resource in this particular
invocation which needs ~0.7s to replenish?  Or something like that?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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