GNU bug report logs - #61514
30.0.50; sadistically long xml line hangs emacs

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 61514 <at> debbugs.gnu.org, mah <at> everybody.org
Subject: Re: bug#61514: 30.0.50; sadistically long xml line hangs emacs
Date: Tue, 21 Feb 2023 08:24:14 -0500

>> SGTM, but isn't 1000 a somewhat low value?  What if we use half of the
>> value of long-line-optimizations-region-size instead?
>>
>
> Here are some benchmarks.  The time taken by Emacs to open the 4 MB
> "n_n_..." file with different regexps are:
>
> "[^<>\n]\\{1,100\\}?\\<": 0.8 seconds
> "[^<>\n]\\{1,1000\\}?\\<": 3.4 seconds
> "[^<>\n]\\{1,10000\\}?\\<": 28.5 seconds
> "[^<>\n]\\{1,65535\\}?\\<": 162.9 seconds
> "[^<>\n]+?\\<": 356.6 seconds
>
> 65535 is the upper limit for such ranges, it's not possible to use
> a larger value.

BTW, personally when I suggested to limit the search I was thinking of
`narrow-to-region` (which bounds both N factors in the N² complexity).

AFAIK this part of the code is intended mostly when editing XML by
hand, where attributes aren't expected to be ridiculously long, so
limiting to a few kB would be perfectly acceptable (and if the search
fails it's not big deal: when the search succeeds we don't *really* know
what it means either, it may be a false positive anyway).


        Stefan

Previous Next

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