bug#25706: 26.0.50; Slow C file fontification

[Alan Mackenzie]

Hello, Ravine.

On Mon, Dec 14, 2020 at 12:50:36 +0530, Ravine Var wrote:
> Alan Mackenzie <acm@muc.de> writes:
> > Have you got the option fast-but-imprecise-scrolling set (or customized)
> > to non-nil?  If not, could I suggest you try it.  It's effect is to stop
> > Emacs fontifying every screen it scrolls over, instead only fontifying
> > screens when it's got no more input commands waiting.  This speeds
> > things up quite a bit on a slower machine.

> Turning on fast-but-imprecise-scrolling improves things by a lot.
> Viewing and scrolling the osprey file is much faster/smoother and the
> screen doesn't freeze.

:-)

> > Please put the following code into your *scratch* buffer (it's the same
> > code I've posted before) and evaluate it:

> >     (defmacro time-it (&rest forms)
> >       "Time the running of a sequence of forms using `float-time'.
> >     Call like this: \"M-: (time-it (foo ...) (bar ...) ...)\"."
> >       `(let ((start (float-time)))
> >         ,@forms
> >         (- (float-time) start)))

> > Then please load osprey_reg_map_macro.h freshly into a buffer, and type
> > (or cut and paste) the following into M-:

> >     (time-it (let ((n 10)) (while (> n 0) (scroll-up) (sit-for 0) (setq n 
> > (1- n)))))

> > What is the reported timing for scrolling these ten screens?

> Running emacs -Q (master + 3 patches) :

> With fast-but-imprecise-scrolling: 0.9250097274780273
> Without fast-but-imprecise-scrolling: 0.8903303146362305

Thanks for doing that further testing.

That's 0.09 seconds per scrolling of a screen.  That is surely an
acceptably low delay.

> I think using the fast-but-imprecise-scrolling option
> is a workaround that can be used in underpowered machines
> for big header files...

Or even in up to date full powered machines.  ;-)  I have it enabled all
the time, and my PC is very similar to your faster one.

So, I propose that these two patches (the big one and the smaller one for
all the c-forward-syntactic-ws's) are sufficient to fix the bug, and I
propose closing it now.  What do you say to that?

I have looked at the other problem you mention (slow scrolling through
the machine-generated function proto_register_rrc in the wireshark file
packet-rrc.c) and have made significant progress towards implementing a
cache for the CC Mode function c-looking-at-or-maybe-in-bracelist, which
should eliminate the long delays.  Have you raised a new bug for this
problem, yet?

-- 
Alan Mackenzie (Nuremberg, Germany).