I can reproduce with shell but if you look at the profiling results you'll see that it's not xterm-color-filter that takes up CPU time, rather Emacs's internal font-locking functions. Which makes me suspect that the issue is caused by some sort of weird interplay between comint and font locking. This issue doesn't exist with eshell (see below for runtime). * CPU profiling for shell - comint-output-filter 2249 94% - font-lock-prepend-text-property 917 38% - put-text-property 910 38% - jit-lock-after-change 889 37% run-hook-with-args 754 31% - font-lock--remove-face-from-text-property 880 36% - put-text-property 866 36% - jit-lock-after-change 850 35% run-hook-with-args 696 29% undo-auto--undoable-change 2 0% - run-hook-with-args 444 18% - comint-postoutput-scroll-to-bottom 444 18% recenter 5 0% xterm-color-filter 3 0% * CPU profiling for eshell - eshell-output-filter 288 69% - eshell-run-output-filters 269 64% - run-hooks 269 64% - eshell-postoutput-scroll-to-bottom 267 64% - walk-windows 267 64% #<compiled 0x412f6d65> 266 63% xterm-color-filter 17 4% command-execute 82 19% ... 44 10% redisplay_internal (C function) 2 0% * Runtime of your ruby trigger in eshell Fabulous run in 1.976468s, 1011.9061 runs/s, 0.0000 assertions/s. * Runtime of your ruby trigger in shell Fabulous run in 9.896460s, 202.0925 runs/s, 0.0000 assertions/s. I'll dig deeper into comint when I get some time.

As an interim before I figure out what's going on, you can try disabling font-locking for your shell mode buffers (e.g. interactively M-x font-lock-mode). This fixes the problem here.

Removing comint-postoutput-scroll-to-bottom from comint-output-filter-functions and disabling buffer undo (M-x buffer-disable-undo) make performance (almost) linear. So, to summarize, it looks like there's a combination of factors that contribute to the exponential slowdown. Activated font-locking in the shell mode buffer. This is (mostly) useless I'd presume, since xterm-color will handle faces just fine by itself, so it can be safely disabled. comint-postoutput-scroll-to-bottom in comint-output-filter-functions triggers frequent recenter operations buffer-undo which can also be disabled (doesn't affect input history). Probably other things. GC can be an issue. Emacs handling of long lines is suspect and so on.

I did a bit of comint digging and can't find anything else that I can immediately tweak to speed speed things up. I ended up disabling font locking for all my shell-mode buffers, this gives me a big speedup and avoids the exponential slowdowns. This is my personal shell-mode config: ``` (setq xterm-color-debug nil comint-output-filter-functions (remove 'ansi-color-process-output comint-output-filter-functions)) (defun xristos/font-lock-function (_) nil) (defun xristos/disable-font-lock () (font-lock-mode -1) (make-local-variable 'font-lock-function) (setq font-lock-function 'xristos/font-lock-function)) (defun xristos/shell-mode-hook () (xristos/disable-font-lock) (add-hook 'comint-preoutput-filter-functions 'xterm-color-filter nil t) ;; TODO: The following depends on font-locking, it's better to write ;; my own mode for similar functionality at some point. ;; (compilation-shell-minor-mode 1) ) (add-hook 'shell-mode-hook 'xristos/shell-mode-hook) ``` I chose to keep comint-postoutput-scroll-to-bottom in comint-output-filter-functions, even though removing it gives significant speedups. I may dig into it and try to write a better performing alternative in the future. I also chose to keep undo in shell-mode buffers since disabling it only provides a small speedup (same for column-number-mode). Thanks for the report.