GNU bug report logs - #7089
23.2; slow ansi-color-apply

Previous Next

Package: emacs;

Reported by: Leo <sdl.web <at> gmail.com>

Date: Thu, 23 Sep 2010 09:14:02 UTC

Severity: normal

Found in version 23.2

Done: Leo <sdl.web <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Leo <sdl.web <at> gmail.com>
Subject: bug#7089: closed (Re: bug#7089: 23.2; slow ansi-color-apply)
Date: Thu, 25 Nov 2010 14:26:03 +0000
[Message part 1 (text/plain, inline)]
Your bug report

#7089: 23.2; slow ansi-color-apply

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 7089 <at> debbugs.gnu.org.

-- 
7089: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7089
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Leo <sdl.web <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7089-done <at> debbugs.gnu.org
Subject: Re: bug#7089: 23.2; slow ansi-color-apply
Date: Thu, 25 Nov 2010 14:30:54 +0000
[Message part 3 (text/plain, inline)]
On 2010-10-31 19:10 +0000, Stefan Monnier wrote:
>> Do you know for sure string-match is slower (more CPU intensive) than
>> re-search-forward?
>
> They should be largely equivalent.  The difference between the two codes
> might be due to replace-match and substring.  I.e. the original
> ansi-color-apply should be at least as efficient as your code (if not
> more) in the case where there are no SGR escape sequences.
>
>
>         Stefan

I was setting out to profile the two versions of the function and
unfortunately I was not able to see the CPU shootup mentioned in the
first message. My result shows my version of ansi-color-apply is almost
twice as slow as the original one. (The code and data used for profiling
are attached.)

So please ignore this bug report.

Leo

[ansi-color-test.el (application/emacs-lisp, attachment)]
[ansi-test.txt (text/plain, attachment)]
[Message part 6 (message/rfc822, inline)]
From: Leo <sdl.web <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: Alex Schroeder <alex <at> gnu.org>
Subject: 23.2; slow ansi-color-apply
Date: Thu, 23 Sep 2010 10:15:41 +0100
I have found ansi-color-apply very expensive and slow.

To test this, do the following

  (remove-hook 'eshell-output-filter-functions 'eshell-handle-ansi-color)
  (add-hook 'eshell-preoutput-filter-functions 'ansi-color-apply)

and do something in eshell that can output a large coloured text such
as:

  cd /usr/include; ack time

where ack is a single file perl script from http://betterthangrep.com/.
The CPU usage should shoot up to very high.

The following version (after brief testing) seems to be noticeably
faster.

(defun ansi-color-apply* (string)
  "A more efficient implementation of `ansi-color-apply' (which see)."
  (let ((face (car ansi-color-context))
        start end fragment escape-sequence)
    ;; If context was saved and is a string, prepend it.
    (if (cadr ansi-color-context)
        (setq string (concat (cadr ansi-color-context) string)
              ansi-color-context nil))
    (with-temp-buffer
      (insert string)
      (setq start (point-min-marker))
      (goto-char start)
      (while (re-search-forward ansi-color-drop-regexp nil t)
        (replace-match ""))
      (goto-char start)
      ;; Find the next escape sequence.
      (while (re-search-forward ansi-color-regexp nil t)
        (setq end (match-beginning 0))
        (when face
          (put-text-property start end 'ansi-color t)
          (put-text-property start end 'face face))
        (setq start (copy-marker (match-end 0)))
        (setq escape-sequence (match-string 1))
        (replace-match "")
        (setq face (ansi-color-apply-sequence escape-sequence face)))
      ;; search for the possible start of a new escape sequence
      (if (re-search-forward "\033" nil t)
          (setq end (match-beginning 0)
                fragment (buffer-substring end (point-max)))
        (setq end (point-max)))
      ;; if the rest of the string should have a face, put it there
      (when face
        (put-text-property start end 'ansi-color t)
        (put-text-property start end 'face face))
      ;; save context
      (if (or face fragment)
          (setq ansi-color-context (list face fragment))
        (setq ansi-color-context nil))
      (buffer-string))))

Leo



This bug report was last modified 14 years and 258 days ago.

Previous Next


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