Saving files of any size is annoyingly slow

[costa]

Description

At some point, a few years back, Spacemacs introduced something that made saving files much slower.

Reproduction guide 🪲

• Start Emacs
• Open some files (with 10 files it will probably be visible very well)
• Change those files without saving them individually (paste like 10 lines in each)
• :wa (save all; and see it taking a couple of seconds at least)

Observed behaviour: 👀 💔
It's much slower than a couple of years ago. It used to take no time at all. Yes, it's Spacemacs, try the same thing in plain Emacs and see the difference.

Expected behaviour: ❤️ 😄
It should be as fast as a couple of years ago. I've been waiting for a fix for this regression, but it never came. Everyone's probably got used to software performance degradation, I dunno.

System Info 💻

• OS: darwin
• Emacs: 29.1
• Spacemacs: 0.999.0
• Spacemacs branch: develop (rev. b86a074)
• Graphic display: t
• Running in daemon: nil
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

(protobuf typescript rust nginx html javascript go docker elixir ruby python yaml emacs-lisp git helm multiple-cursors neotree)

• System configuration features: ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM ZLIB

[fnussbaum]

Thanks for the report. Using the profiler with SPC h P ... on my system indicates that this is due to garbage collection. Try setting dotspacemacs-gc-cons to (800000 0.1), which keeps the default Emacs values for gc-cons-threshold and gc-cons-percentage.

I am not sure whether this leads to performance problems elsewhere, but setting gc-cons-threshold as large as 100000000 does not seem to be universally recommended, so maybe we should reconsider this default value.

[fnussbaum]

Actually, the gc-cons values should be fine, sorry for the noise. This might be an upstream issue in undo-tree, introduced in https://gitlab.com/tsc25/undo-tree/-/commit/ffd18cd6250467273815349b0a6c0e569e64ae3d: undo-list-transfer-to-tree calls garbage-collect directly. I don't think this is necessary (note the changes in https://gitlab.com/tsc25/undo-tree/-/commit/8842bb53396384aeb0d7d04601964c661eb5e15a), hence I would suggest trying the following advice, which seems to solve the performance problem on my system:

(define-advice undo-list-transfer-to-tree (:around (orig-fun &rest args) ignore-gc)
  (cl-letf (((symbol-function 'garbage-collect) #'ignore))
    (apply orig-fun args)))

[88-percent]

Not sure if it's the same issue, but I've tracked something similar in my system associated with undo-tree too. May not be the same issue however, as the behavior you describe is accompanied by really long launch times for me.

I should probably try fnussbaum's recommended advice, but I've found a quick fix is to manually delete any large files in ~/.emacs.d/.cache/undo-tree-history before launching emacs.

[costa]

oh, undo-tree is one of the less successful spacemacs components, as far as i'm concerned, i did have trouble with it in the past, i don't use its functionality -- though i would like to use something like it, given that it would function properly -- and now, this. i wouldn't like to hack into it with these advices -- for me, it defies the purpose of using spacemacs. i would just want to replace undo-tree with something else instead then...

[bcc32]

undo-tree also doesn't seem to be actively maintained anymore---I have tried multiple times to send (basically trivial improvement) patches to the maintainer without any response. That, coupled with the fact that it seems to often lose undo information, makes me inclined to think it should just be removed from Spacemacs.

[smile13241324]

Yes I am also in favour of removing it we already have too many non maintained packages in Spacemacs.

PRs are welcome

[fnussbaum]

As of eb6bd5e, there is now an option dotspacemacs-undo-system that can be customized to disable undo-tree.

[costa]

Great news, I will make an effort to check undo-fu and friends on my machines as soon as possible.

[88-percent]

This is great.

Is anyone able to explain how best to chose between undo-fu and undo-redo?

I think undo-redo is now built in, but am I correct that undo-fu needs to be installed from melpa? (ie: no layer)

Will evil-undo-system be migrated automatically after assigning a value to dotspacemacs-undo-system or should I be assigning values to both of these manually?

[costa]

it seems that changing the undo system does the trick, for this issue at leaast, thanks all, kudos to maintainers

[fnussbaum]

Is anyone able to explain how best to chose between undo-fu and undo-redo?

It should not matter too much, and one should be able to switch between those without losing undo data. undo-fu seems to provide some minor additional functionality, see https://codeberg.org/ideasman42/emacs-undo-fu, like accessing the full non-linear undo history with the same command (without vundo). See also https://codeberg.org/ideasman42/emacs-undo-fu/issues/20, perhaps the author will provide an answer there.

I think the built-in undo-redo would be a good default.

I think undo-redo is now built in, but am I correct that undo-fu needs to be installed from melpa? (ie: no layer)

Yes, it should get installed automatically.

Will evil-undo-system be migrated automatically after assigning a value to dotspacemacs-undo-system or should I be assigning values to both of these manually?

evil-undo-system is assigned automatically.

[88-percent]

Thanks so much! I went with undo-redo.

I'm really surprised with the speed bump this has given me. I hadn't understood that that the delay in my agenda views was caused by undo-tree. Great improvement.