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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
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 14:24:01 +0300

> Date: Tue, 16 Aug 2022 22:32:23 +0300
> Cc: 57245 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 16.08.2022 19:54, Eli Zaretskii wrote:
> > Stefan, can you see why syntax-related stuff in sgml-mode is so heavy
> > here?
> 
> nxml-syntax-propertize might well be heavier than average, but the delay 
> scales linearly with the size of the file.

Which is generally not a good scaling factor, especially if the
coefficient is quite large (as it seems to be in this case).

> Which seems to be exactly the behavior the "font-lock narrowing" was 
> supposed to guard from?

No.  It wasn't supposed to fix modes that foolishly scan the buffer
from BOB to point.  It was supposed to fix modes which scan from the
beginning of line, and that is (a) only a problem when lines are very
long, and (b) much harder to solve in the mode itself, because
font-lock very frequently uses anchored regexps and otherwise likes to
start from BOL, and syntax processing also likes starting from BOL.

Btw, does nXML and/or sgml-mode use libxml for their analysis?  If
not, why not? wouldn't that be faster (and possibly more accurate)?

Previous Next

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