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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

And I guess the order makes no difference there?
What about with the simpler patch that passes the bounds of the first
function to the subsequent ones?  I suspect this should give us
something like 21.2s when the ordering is favorable and 22.6s when the
ordering is not, right?

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

[ Well, 499 plus the effect of increasing the specified region by
  rounding it up to whole lines and things like that, of course ;-)  ]

> If we were to increase jit-lock-chunk-size to, say 2000, more of the
> next screen would be getting fontified, perhaps wastefully.

Indeed, I was thinking of increasing it only to 1000.

> Indeed.  With jit-lock-chunk-size at 2000, time-scroll on xdisp.c takes:
>
> (current code): 16.4s
> (new proposed code): 16.1s

A larger chunk should also make the impact of the order of the functions
less important (because the "excess" work returned in `jit-lock-bounds`
should be largely independent from the size of the region).


        Stefan