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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: mah <at> everybody.org, 61514 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: bug#61514: 30.0.50; sadistically long xml line hangs emacs
Date: Tue, 21 Feb 2023 15:07:24 +0200

> Date: Tue, 21 Feb 2023 12:37:11 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: mah <at> everybody.org, 61514 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
> 
> 
> >
> > 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.

OK, but does it sound outrageous to have more than 1K of non-newline
characters in a row without any brackets?

At the very least, maybe make the value be in some variable?

Previous Next

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