Re: bug-reference-prog-mode slows down CC Mode's scrolling by ~7%

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Sat, Sep 04, 2021 at 11:00:53 -0400, Stefan Monnier wrote:
> > , it takes 27.9s.  So it would seem the cost of having a jit-lock
> > function returning a jit-lock-bounds structure when it's not the first
> > function is high.  That's using the strategy of a full refontification of
> > the "extra" regions of the buffer returned in that structure.

> How does it compare to the performance with the old/current
> jit-lock code?

That takes ~22.6s.

> > Maybe that strategy is not optimal.

> I think it leads to many calls to the client functions with small
> regions, which for font-lock at least is not optimal indeed.

> Maybe to speed things up, another option is to grow the chunk size
> a bit.

Maybe.  An advantage of a small chunk size is that fontifying a single
screen can be done with a maximum 499 bytes "inefficiency" off the end
of a screen.  If we were to increase jit-lock-chunk-size to, say 2000,
more of the next screen would be getting fontified, perhaps wastefully.
I don't know how important this is.  Maybe I should try it.

Indeed.  With jit-lock-chunk-size at 2000, time-scroll on xdisp.c takes:

(current code): 16.4s
(new proposed code): 16.1s

..  This speed up may well be particular to CC Mode.

Let's try jit-lock-chunk-size at 8000:

(current code): 15.1s
(new proposed code): 15.1s

..  So, yes, it would seem a larger chunk size is advantageous for CC
Mode.  In Emacs Lisp Mode, scrolling through jit-lock.el takes:

(500): 0.195s
(8000): 0.184s

..  So the advantage of a bigger chunk size is less marked, here.

Maybe we should consider increasing the default jit-lock-chunk-size.


>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).