Truncating is too slow for long buffers

[thomasf]

Deleting chunks would probably be better.. Maybe using threshold/amount instead of a maximum value.
The slowdown happens if the buffer is visible only.

[shosti]

Could you add some more context/steps to reproduce? And by "long" do you mean processes with a lot of output or a large truncation setting? (I've found that processes with a lot of output are too slow with or without truncation, due to Emacs' text-handling.)

[thomasf]

I think it's due to the redisplay being called and having to rework large parts of the buffer line removed..

For the time being, I'm using this:

  (setq my-prodigy-truncate-amount 5000
          my-prodigy-truncate-threshold 15000)
    ;; NOTE overriden
    (defun prodigy-truncate-buffer (service _)
      "Truncate SERVICE process view buffer to its maximum size."
      (prodigy-with-service-process-buffer service
        (when (>  (line-number-at-pos (point-max)) my-prodigy-truncate-threshold)
          (save-excursion
            (goto-char (point-min))
            (forward-line my-prodigy-truncate-amount)
            (delete-region (point-min) (point))))))

By truncating only at every 5000th lines emacs is almost usable since it only freezes up a short time at every truncation.

I think i might add that I also have compilation-minor-mode enabled for the output buffers which adds quite a few regexps which I guess affects redisplay time.

[thomasf]

I can reproduce by just hitting the max lines while having the log buffer visible and for any added (truncated) line emacs stops for ~ 200-600ms. Insertion only seems to give real slown downs somewhere around 70-100k lines on my computer.

[thomasf]

An intentionally extreme example where the threshold really help:

https://www.youtube.com/watch?v=jk5iCkQcYQI

The freezing seen at every 5000th line in the video feels only slightly longer than the freeze for each line with the default truncation code. Having multiplication in mind the total effect is large.