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

[Eli Zaretskii]

> Date: Thu, 04 Aug 2022 15:08:07 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: gerd.moellmann@gmail.com, 56682@debbugs.gnu.org, 
> monnier@iro.umontreal.ca, 
>     dgutov@yandex.ru
> 
> 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.  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.

> But you're right, this slowdown has little to do with bidi.  A file with a 
> sufficiently long single line of Arabic text has the same problem.  (But 
> not one with a line of Hebrew text.)

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 I think we are good here, do you agree?