bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7069: Compilation from within emacs becomes slower and slower until


From: Stefan Monnier
Subject: bug#7069: Compilation from within emacs becomes slower and slower until Emacs is restarted
Date: Wed, 20 Apr 2011 10:10:30 -0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]