bug#56393: Actually fix the long lines display bug

[Gregory Heytings]

> > Font lock does slow things down, see the NEWS entry.  But it also slows 
> > things down on much smaller files (see the long-line-excerpt.xml file I 
> > sent you).  As I said, to me the slowdown of font locking is a separate 
> > problem, as is shown by the fact that turning it off removes the 
> > remaining slowdowns in many/most cases.  There are in fact four 
> > separate problems here:
> >
> > 1. slowdowns caused by long lines,
> >
> > 2. slowdowns caused by multibyte characters in long lines (which are 
> > not solved by solving 1),
> >
> > 3. slowdowns caused by font locking,
> >
> > 4. slowdowns caused by major and minor modes (pre and post-command 
> > hooks and the like).
> >
> > This bug "only" solves 1 and 2.  And as I said, I can try to look at 3 
> > if you want, but not now.
>
> I'm asking whether applying the "restriction" where we call 
> Vfontification_functions from the display engine won't also solve 3.

It doesn't, see again the long-line-excerpt.xml file I sent you.  It is 
only 30K long, which would be a typical size for a restriction, and 
editing that file is slow when font locking is on and fast when font 
locking is off.

What I would do (but I'm pretty sure you wouln't agree with that) is to 
measure the time taken by fontification-functions in 
handle_fontified_prop, and whenever that time is above a certain threshold 
(say 0.25 or 0.5 seconds), to set fontification-functions to nil in that 
buffer.  For example, if you load dictionary.json (with "y") and type C-e, 
fontification-functions take about 2 seconds to complete.

But fontification-functions are not the only problem here.  What I also 
observe is that, for example, moving in a fontified buffer takes (much) 
longer than moving in a non-fontified buffer.  For example, in 
long-line.xml, vertical-motion takes about 40 ms backward and 10 ms 
forward in a non-fontified buffer, and about 180 ms backward and 40 ms 
forward in a fontified buffer.