[Top][All Lists]

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

[Emacs-bug-tracker] bug#7089: closed (23.2; slow ansi-color-apply)

From: GNU bug Tracking System
Subject: [Emacs-bug-tracker] bug#7089: closed (23.2; slow ansi-color-apply)
Date: Thu, 25 Nov 2010 14:26:02 +0000

Your message dated Thu, 25 Nov 2010 14:30:54 +0000
with message-id <address@hidden>
and subject line Re: bug#7089: 23.2; slow ansi-color-apply
has caused the GNU bug report #7089,
regarding 23.2; slow ansi-color-apply
to be marked as done.

(If you believe you have received this mail in error, please contact

7089: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7089
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- 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

  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

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


--- End Message ---
--- Begin Message --- Subject: Re: bug#7089: 23.2; slow ansi-color-apply Date: Thu, 25 Nov 2010 14:30:54 +0000 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (Mac OS X 10.6.5)
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.


Attachment: ansi-color-test.el
Description: ansi-color-test.el

Attachment: ansi-test.txt
Description: ansi-test.txt

--- End Message ---

reply via email to

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