bug#56682: Fix the long lines font locking related slowdowns

[Gregory Heytings]

> > For example C-p, C-n, C-v, M-v.  C-f and C-b also, but much less so.
> >
> > For example, open the file and do M-g c 70000 RET.  This took about 5 
> > seconds.  Now do C-n, this again took about 5 seconds.  With the 
> > optimizations, M-g c 70000 RET is almost immediate, and C-n there takes 
> > less than a second.
>
> I'm on the branch, so I am _after_ the optimizations.  I thought you 
> said even after that the navigation is sluggish.

Yes, that's what I said indeed.

> I see somewhat slower response than in "normal" files, but my build is 
> unoptimized, so where it takes 3 or 4 seconds, and optimized build 
> should be almost instantaneous. And that looks good enough to me, since 
> being a bit slower in such files is IMO fine.

It's not really "almost instantaneous", moving point can take (depending 
on factors I do not understand at the moment) something between 0.2 
seconds and 2 seconds.

> OK.  Text that goes through character compositions is expected to be 
> slower in redisplay, because character composition in Emacs works by 
> calling into Lisp.

So Arabic text goes through character compositions and Hebrew text 
doesn't, is that correct?

> So I think we are good here, do you agree?

Hmmm...  I still think it would be possible to do better.  With the above 
recipe (M-g g 70000 RET C-n), composition_compute_stop_pos is called 
627663 times and uses about 2 seconds of CPU time.  What surprises me (and 
makes me believe it's perhaps possible to do better) is that it is called 
repeatedly with the same arguments.  For example, when doing C-n it is 
called 26 times with charpos = 69980.