bug#5599: 23.1; compilation error regexp "watcom" slow on long lines

bug#5599: 23.1; compilation error regexp "watcom" slow on long lines

[Kevin Ryde]

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

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@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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: compile.el.watcom.diff --]
[-- Type: text/x-diff, Size: 425 bytes --]

--- 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))
 

[-- Attachment #3: foo.el --]
[-- Type: application/emacs-lisp, Size: 298 bytes --]

[-- Attachment #4: Type: text/plain, Size: 1076 bytes --]



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

bug#5599: 23.1; compilation error regexp "watcom" slow on long lines

[Chong Yidong]

> 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.