0

A bunch of creating and killing buffers in my setup and I can't track down what is it. Here is my debug code:

(add-hook 'kill-buffer-hook
          (lambda() (message "Killed: %s / %s" major-mode (buffer-name))))

which results in something like this:

Killed: fundamental-mode /  *temp* [170 times]
Killed: fundamental-mode /  *string-output*
Killed: fundamental-mode /  *temp*
Killed: fundamental-mode /  *string-output*
Killed: fundamental-mode /  *temp*
Killed: fundamental-mode /  *string-output*
Killed: fundamental-mode /  *temp*
Killed: fundamental-mode /  *string-output*
Killed: fundamental-mode /  *temp*
Killed: fundamental-mode /  *string-output*
Killed: fundamental-mode /  *temp*
Killed: fundamental-mode /  *string-output*
Killed: fundamental-mode /  *temp* [234 times]
Killed: fundamental-mode /  *string-output*
Killed: fundamental-mode /  *temp*
Killed: fundamental-mode /  *string-output*
Killed: fundamental-mode /  *temp*
Killed: fundamental-mode /  *string-output*
Killed: fundamental-mode /  *temp*
Killed: fundamental-mode /  *string-output*
Killed: fundamental-mode /  *temp*
Killed: fundamental-mode /  *string-output*
Killed: fundamental-mode /  *temp*
Killed: fundamental-mode /  *string-output*
Killed: fundamental-mode /  *temp* [220 times]

Sometimes it peaks a dozen a second. I swapped my .emacs.d with a Doom setup (my current is a Spacemacs heavily tuned) and those killings still happen, but seldom. Especially when idle, nothing is observed, while with my setup it's this very frequent and comes in batches. It's causing lots of slow downs, cursor movements are the main culprit, generating more than a bunch per move.

4
  • I would start by profiling the code.
    – NickD
    Commented Apr 18, 2020 at 3:51
  • 1
    Emacs creates temporary buffers all the time for all kinds of reasons. Buffers are a fundamental data structure for Emacs -- they are often used like other languages use strings. Clearly something in your Spacemacs config is using them more often than your Doom config, but that doesn't necessarily mean that anything is wrong.
    – phils
    Commented Apr 18, 2020 at 7:03
  • To find out what is causing it, use (backtrace) or (backtrace-frames) to discover the call stack at any given point.
    – phils
    Commented Apr 18, 2020 at 7:07
  • 1
    You can also M-x debug-on-entry RET kill-buffer, and look at the backtrace. Then debug-on-entry a function that seems to be initiating the kill-buffer calls, instead of kill-buffer itself.
    – Drew
    Commented Apr 18, 2020 at 15:49

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.