[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#7089: 23.2; slow ansi-color-apply
From: |
Leo |
Subject: |
bug#7089: 23.2; slow ansi-color-apply |
Date: |
Tue, 02 Nov 2010 00:23:06 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (Mac OS X 10.6.4) |
On 2010-11-01 03:10 +0800, Stefan Monnier wrote:
>>>> The following version fixed some glitches in setting ansi-color-context.
>>>> Also I have received an email from Alex that welcomes the improvement.
>>>> Let me know if I should send a patch in.
>>> Yes, a patch would be nice. Also a ChangeLog explaining the change
>>> (which should hopefully explain why the new code is faster) would
>>> be welcome.
>
>> Attached to the end of this message. I basically rewrite
>> ansi-color-apply using re-search-forward (as in
>> ansi-color-apply-on-region) which seems to be an order more efficient
>> than string-match.
>
>> I have been using the new version in eshell and it is almost as
>> efficient as ansi-color-apply-on-region. It is very painful to use the
>> original ansi-color-apply.
>
> Any reason why your new code does something similar to
> ansi-color-apply-on-region rather than calling
> ansi-color-apply-on-region?
`ansi-color-apply-on-region' uses overlays while `ansi-color-apply' uses
text properties.
>> 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
Thanks for that info.
Leo
- bug#7089: 23.2; slow ansi-color-apply,
Leo <=