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

Previous Next

Full log

Message #50 received at 57245 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57245 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#57245: 29.0.50; M-> in a large XML file (without long lines)
 is slow
Date: Wed, 17 Aug 2022 15:30:22 +0300

On 17.08.2022 15:16, Eli Zaretskii wrote:
>> Date: Wed, 17 Aug 2022 14:46:46 +0300
>> Cc:57245 <at> debbugs.gnu.org,monnier <at> iro.umontreal.ca
>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>>
>> On 17.08.2022 14:36, Eli Zaretskii wrote:
>>>> Date: Wed, 17 Aug 2022 01:20:38 +0300
>>>> Cc: Eli Zaretskii<eliz <at> gnu.org>,57245 <at> debbugs.gnu.org
>>>> From: Dmitry Gutov<dgutov <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.