GNU bug report logs - #18013
looking-back is inefficient

Previous Next

Package: emacs;

Reported by: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>

Date: Mon, 14 Jul 2014 09:48:02 UTC

Severity: minor

Tags: wontfix

Found in version 24.3.92

Done: npostavs <at> users.sourceforge.net

Bug is archived. No further changes may be made.

Full log


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

From: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>
To: Andreas Schwab <schwab <at> suse.de>
Cc: Nicolas Richard <theonewiththeevillook <at> yahoo.fr>, 18013 <at> debbugs.gnu.org
Subject: Re: bug#18013: 24.3.92;
 looking-back "[^\n]" taking a lot of time in large buffers (was:
 Infloop in re_search_2)
Date: Mon, 14 Jul 2014 13:12:34 +0200
Andreas Schwab <schwab <at> suse.de> writes:

> Nicolas Richard <theonewiththeevillook <at> yahoo.fr> writes:
>
>> I'll admit that (looking-back "[^\n]") is not exactly the canonical way
>> to test for (not (bolp)), but should it make an infloop ? I can't
>> reproduce though.
>
> I don't think it infloops, it just takes a very long time.  Since this
> is running in a process filter interrupts are disabled, so you have to
> be extra careful with what you do here.

It seems you were totally right, thanks ! Here's a repro test case :

# pick up a big file or make one :

$ yes | dd bs=1MB iflag=fullblock count=50 > foobartest 
50+0 enregistrements lus
50+0 enregistrements écrits
50000000 octets (50 MB) copiés, 0,853576 s, 58,6 MB/s

# open it in an emacs buffer and try looking-back :

$ time emacs --batch -Q --eval '(with-temp-buffer (insert-file-contents "foobartest") (goto-char (point-max)) (princ "Looking back...") (looking-back "[^\n]") (princ "done!") (terpri))'

"Looking back..."

"done!"


real	0m8.577s
user	0m8.541s
sys	0m0.047s

As you see it takes more than 8 seconds on my system, most of that time
is spent looking-back (inserting the file is quick).

(looking-back "[^\n]") is bad code, so I totally deserve this. Still, is
it possible to make the search smarter when the match is supposed to be
"anchored" at point ? Otherwise let's just close this bug.

-- 
Nico.




This bug report was last modified 8 years and 116 days ago.

Previous Next


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