Better compilation-mode performance?

[sebastiansturm]

Sometimes I use compile to run scripts that execute quickly, but generate lots of output (maybe unexpectedly so). Here's a synthetic TypeScript test case:

let line = "word ";
for (let i = 0; i < 5; ++i) line += line;
line += "\n";
for (let i = 0; i < 50000; ++i) {
  process.stdout.write(line);
}

in my terminal, tsx test.ts finishes after 0.2s. In emacs, using compile, I get around 180s. Much of that, I think, is caused by comint-truncate-buffer. Doing the following,

(defun my/truncate-compile-buffer (&optional _string)
  (let ((upper-limit 400000)
        (rem-size 200000))
    (when (> (buffer-size) upper-limit)
      (let ((inhibit-read-only t))
        (delete-region (point-min) (- (point-max) rem-size))))))

  (remove-hook 'compilation-filter-hook #'comint-truncate-buffer)
  (add-hook 'compilation-filter-hook #'my/truncate-compile-buffer)

the runtime reduces to 21s. With (setq compilation-scroll-output nil), to about 12s.

Is this a good candidate for inclusion into doom-emacs proper? Is comint-truncate-buffer's property of only deleting complete lines considered essential? Also, perhaps we could dynamically disable compilation-scroll-output once we have to truncate, and scroll once compilation has finished? And perhaps there's a way to speed up things further, since the terminal (kitty, in my case) still outpaces emacs by orders of magnitude?

[hlissner]

I see what you mean. Rate-limiting comint-truncate-buffer is a good start, since its forward-line calls get increasingly more expensive the longer the buffer gets, and it does it for every chunk of output it processes (which is typically once per line).

Here is a simpler version (operating on top of Doom's defaults). See if this helps you as much as it does me:

;;; add to $DOOMDIR/config.el
(after! compile
  (setq compilation-max-output-line-length nil)  ; don't scan each line's length.

  (remove-hook 'compilation-filter-hook #'comint-truncate-buffer)
  (add-hook! 'compilation-filter-hook
    (defun doom-comint-truncate-buffer-h (&optional _string)
      "Rate-limit `comint-truncate-buffer' in compilation-mode buffers."
      (if (> (buffer-size)
             ;; HACK: Approximate this because counting lines is prohibitively
             ;;   expensive in longer buffers, especially for
             ;;   `compilation-filter-hook' which fires rapidly.
             (* 80 comint-buffer-maximum-size))
          (let ((gc-cons-threshold most-positive-fixnum)
                (gc-cons-percentage 1.0))
            (with-silent-modifications
              (comint-truncate-buffer)))))))

Suppressing GC while compilation is running is another thing to try:

;;; add to $DOOMDIR/config.el
(defvar old-gc-cons-threshold nil)
(add-hook! 'compilation-start-hook
  (defun doom-compilation-start-h (_)
    (unless old-gc-cons-threshold
      (setq-local old-gc-cons-threshold (cons gc-cons-threshold gc-cons-percentage)
                  gc-cons-threshold most-positive-fixnum
                  gc-cons-percentage 1.0))))
(add-hook! 'compilation-finish-functions
  (defun doom-compilation-finish-h (buf _)
    (with-current-buffer buf
      (when old-gc-cons-threshold
        (setq-local gc-cons-threshold (car old-gc-cons-threshold)
                    gc-cons-percentage (cdr old-gc-cons-threshold))
        (kill-local-variable 'old-gc-cons-threshold)))))

Is comint-truncate-buffer's property of only deleting complete lines considered essential?

Depends on the output. It could upset formatting and disrupt text properties applied by ansi-color-compilation-filter (particularly where error messages are concerned), for two. By the principle of least suprise, I'd prefer not to remove it.

[sebastiansturm]

thank you so much for your quick and detailed reply! Dialing down GC temporarily is probably a good idea, but I haven't evaluated it yet because I'm running a build of the igc branch where these settings have no effect.

Re-running my test script, first using my own patch shown in my original message, I'm still getting 21s with the default compilation-scroll-output and 12s with it set to nil (so at least what I'm doing seems to be fairly reproducible).

With your patch (again, really minus the GC part because on my build that doesn't take effect) I'm getting 20s for the vanilla version, and 9s with compilation-scroll-output set to nil, so this is already a good deal better than what I had even without any GC optimizations.

I do get another large speedup (from those 9s to 2s) using the following advice, but unfortunately it's of little practical use to me right now as I don't know in advance whether the commands I want to run actually require a terminal. Haven't looked into this further yet; perhaps there is a way to realize at least parts of this potential further speedup without breaking the "needs terminal" use case?

(advice-add 'compile :around
              (lambda (orig-fun &rest args)
                (let* ((comint (nth 1 args))
                       ;; it was my assumption that we need a pty if and only if comint is non-nil,
                       ;; but that is not true. Also, I didn't actually test the comint path, because
                       ;; of the abovementioned issues with the non-comint path
                       (default-process-connection-type process-connection-type)
                       (process-connection-type (if comint default-process-connection-type nil)))
                  (apply orig-fun args))))

[sebastiansturm]

thanks for pushing these changes to master!