bug#57245: 29.0.50; M-> in a large XML file (without long lines) is slow

[Dmitry Gutov]

On 17.08.2022 15:16, Eli Zaretskii wrote:
> > Date: Wed, 17 Aug 2022 14:46:46 +0300
> > Cc:57245@debbugs.gnu.org,monnier@iro.umontreal.ca
> > From: Dmitry Gutov<dgutov@yandex.ru>
> >
> > On 17.08.2022 14:36, Eli Zaretskii wrote:
> > > > Date: Wed, 17 Aug 2022 01:20:38 +0300
> > > > Cc: Eli Zaretskii<eliz@gnu.org>,57245@debbugs.gnu.org
> > > > From: Dmitry Gutov<dgutov@yandex.ru>
> > > >
> > > > Otherwise, syntax-wholeline-max seems to be doing its job fine: if I
> > > > comment out the narrowing code in handle_fontified_prop (or switch to
> > > > the branch I posted previously), two XML files -- one with long lines
> > > > and one without (the files differ only by addition of newlines) -- show
> > > > approximately the same delay on M->.
> > > Doesn't syntax-wholeline-max only affect long lines?
> > Its purpose is to handle the slowdown which occurred specifically on
> > long lines because of
> > font-lock-extend-region-functions/syntax-propertize-extend-region-functions.
> > Now that it works -- I don't see any particular slowdowns on long lines,
> > even with narrowing disabled.
> >
> > And the performance of M-> depends solely on the size of a file. In my
> > XML test files, at least.
> Is that a yes?

Yes, it's a "yes".

Stefan said:

> font-lock does suffer from long lines, so the current code's handling
> of font-lock makes some sense

Meaning that narrowing around font-lock on long lines makes sense.

And I replied that no, syntax-wholelines-max should be dealing with long 
lines issues in font-lock already.

>  Because if it is, then what does this have to do with
> the issue of nXML not being scalable enough?

Narrowing around font-lock shouldn't be conditioned on the presence of 
long lines. It either should be done unconditionally (with larger 
radius, I guess), or not at all.