GNU bug report logs - #7069
Compilation from within emacs becomes slower and slower until Emacs is restarted

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Hamren <hamren <at> sdu.se>
Cc: Jan Djärv <jan.h.d <at> swipnet.se>, 7069 <at> debbugs.gnu.org
Subject: Re: Compilation from within emacs becomes slower and slower until
	Emacs is restarted
Date: Wed, 20 Apr 2011 10:10:30 -0300

> 	(add-hook 'compilation-mode-hook
> 	  (lambda () (setq compilation-error-regexp-alist
> 	      (cons
> 	       ;; Quartus II error messages
> 	       '(".*Verilog .* at \\(.+\\)(\\([0-9]+\\)): .*" 1 2)
> 	      compilation-error-regexp-alist))))

There are various optimizations you can do on this regexp (such as
remove the trailing ".*"), but the only one I can see that should make
a significant difference in terms of performance is the leading ".*".
I.e. remove the ".*" at the beginning (compilation regexps are not
anchored at the BOL since Emacs-22, IIRC).  This should speed things up
significantly.  If you insist on keeping the ".*" because you like the
resulting highlighting, then add a "^" before it.
  
> I haven't looked further into why this should be a problem.

I can't think of any reason why this regexp should make compilation
become slower (I can see why it would make it slow, but unless lines
become longer over time, it should keep the same slowness at the end as
it had at the beginning).

Then again, this may depend on the version of Emacs you're using.
I've made some changes to the way compilation messages are parsed in the
upcoming Emacs-24 code (not specifically for performance reasons, but it
does impact performance), so if you could try out the development code
that would be helpful: I'd like to resolve such performance bugs before
Emacs-24 is released.

> The regexp is quite simple, and doesn't match when compiling with g++.

Depending on the shape of the regexp, the "doesn't match" case can be
the worst case, because the regexp-matcher has to try *all* the possible
ways in which it might match before reporting a match failure, whereas
a successful match would stop as soon as the first way to match
is found.


        Stefan

Previous Next

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