GNU bug report logs - #5599
23.1; compilation error regexp "watcom" slow on long lines

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 5599 in the body.
You can then email your comments to 5599 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Kevin Ryde <user42 <at> zip.com.au>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.1; compilation error regexp "watcom" slow on long lines
Date: Fri, 19 Feb 2010 08:30:58 +1100

[Message part 1 (text/plain, inline)]

If a compilation-mode buffer has a very long line, the `watcom' error
regexp pattern is very slow at not matching.  For example the foo.el
below takes my old pc about 20 seconds to match nothing.

The line in foo.el is 10,000 chars long, which might seem improbable,
but in fact arises very easily from a "make" echoing a list of filenames
from a distribution, eg. 200 filenames averaging 50 chars each including
paths.  (I've got one dist where the make spits 12,000 char lines, and
another repeated 1500 char lines ...).

I suppose the optional drive letter part of the pattern makes it
backtrack to every character.  I wonder if it could anchor to the start
of the line to restrict that.  (The alternative could be to loosen
what's considered a filename there.)

2010-02-18  Kevin Ryde  <user42 <at> zip.com.au>

	* progmodes/compile.el (compilation-error-regexp-alist-alist): In
	`watcom' add "^" for filename only at start of line.  Avoids
	slowness backtracking to every char of a long line, O(N^2) in the
	length, eg. 20 seconds to fail to match a 10,000 char line.

[compile.el.watcom.diff (text/x-diff, inline)]

--- compile.el.~1.504.~	2009-11-26 10:28:08.000000000 +1100
+++ compile.el	2010-02-18 19:39:05.000000000 +1100
@@ -350,7 +350,7 @@
      "^\\([^, \n\t]+\\), line \\([0-9]+\\), char \\([0-9]+\\)[:., \(-]" 1 2 3)
 
     (watcom
-     "\\(\\(?:[a-zA-Z]:\\)?[^:(\t\n]+\\)(\\([0-9]+\\)): ?\
+     "^\\(\\(?:[a-zA-Z]:\\)?[^:(\t\n]+\\)(\\([0-9]+\\)): ?\
 \\(?:\\(Error! E[0-9]+\\)\\|\\(Warning! W[0-9]+\\)\\):"
      1 2 nil (4))
 

[foo.el (application/emacs-lisp, inline)]

[Message part 4 (text/plain, inline)]

In GNU Emacs 23.1.1 (i486-pc-linux-gnu, GTK+ Version 2.16.5)
 of 2009-09-14 on raven, modified by Debian
configured using `configure  '--build=i486-linux-gnu' '--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_AU
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-1-unix
  default-enable-multibyte-characters: t

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kevin Ryde <user42 <at> zip.com.au>
Cc: 5599 <at> debbugs.gnu.org
Subject: Re: 23.1; compilation error regexp "watcom" slow on long lines
Date: Sat, 20 Feb 2010 08:54:39 -0500

> If a compilation-mode buffer has a very long line, the `watcom' error
> regexp pattern is very slow at not matching.  For example the foo.el
> below takes my old pc about 20 seconds to match nothing.
>
> I suppose the optional drive letter part of the pattern makes it
> backtrack to every character.  I wonder if it could anchor to the start
> of the line to restrict that.

Yes, I think that's fine.  I've checked in your patch, with a small
modification to allow whitespace in front of the drive letter part.

Previous Next

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