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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 57245 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: bug#57245: 29.0.50; M-> in a large XML file (without long lines) is slow
Date: Tue, 16 Aug 2022 14:40:33 -0400

> Thanks.  It looks like some problem in nXML mode or in syntax.c or in
> how nXML uses the syntax stuff.  Maybe the code there is simply not
> scalable.
>
> Stefan, can you see why syntax-related stuff in sgml-mode is so heavy
> here?

IIRC the sgml/xml/nxml code for syntax-propertize is fairly
costly, indeed.  It can probably be reimplemented in a more efficient
way, but someone will/would have to sit down and think about how to
do that.

[ Some `syntax-propertize-function`s (like cperl-mode's) have been
  "hacked" in an unsatisfactory way by taking
  existing-but-not-fully-understood code and wrapping it so as to make
  it usable for `syntax-propertize-function`.  The result works but it
  could suffer from inefficiencies due to the fact that it's used in
  a different context from the one for which it was designed.
  Some of nXML's code suffers from similar issues, so I thought maybe
  that would be part of the problem, but AFAICT those don't have any
  impact in this case.  ]

IOW, I think the issue is that our syntax tables aren't a good fit for
SGML's syntax, so we just have to work harder than for other modes.

> What the above profile doesn't show is that this code creates
> tons of garbage, so GC is called a lot, and adds its share of
> slowdown.

Hmm... I wonder where this might come from.  As you say, the profile
doesn't show it: 95% in command-execute suggests less than 6% spent in
the GC.


        Stefan

Previous Next

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