Re: How the long-lines "optimisation" breaks font locking.

[Alan Mackenzie]

Hello, Eli.

On Thu, Aug 04, 2022 at 15:54:34 +0300, Eli Zaretskii wrote:
> > Date: Thu, 4 Aug 2022 10:44:05 +0000
> > Cc: emacs-devel@gnu.org, Gregory Heytings <gregory@heytings.org>
> > From: Alan Mackenzie <acm@muc.de>

[ .... ]

> > > .... because if you, instead of a 10K line in that C++ file, inserted
> > > a 1M line, then Emacs would previously hang indefinitely, but with the
> > > optimisation, it doesn't.

> > Well I tried CC Mode with a 1,000,000 character raw string.  It was
> > indeed a bit sluggish but "hang indefinitely" is an exaggeration.

> Try it with a 20MB raw string, then.  And, for good measure, in an
> unoptimized build.  These are the cases we are trying to make
> workable.

> If all you are saying is that the default value of long-line-threshold
> is too low, we can definitely discuss a better value.

> > Having loaded the file in C++ Mode (without the spiking of
> > narrow-to-region and widen), it took 90 seconds for M-> (first time).

> And you consider that reasonable?

No, it wasn't reasonable, but neither was it "hang indefinitely".

The problem was a single font-lock clause, after whose removal, the M->
took about 1 second (first time) in the file with a 1,000,000 long line.
This clause can be put back into CC Mode and optimised, probably by
checking for being inside a literal.

All the other sluggishness has also vanished with that change.  I still
get the overflow in the regexp engine stack on inserting text.  That,
again, is a bug that surely can be fixed.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).