Improving Emacs Performance

> Disable things like syntax checking as you type You're talking about linting? It's hard for me to imagine anyone going back to linting on save... I can't imagine this being a significant source of slowness. It's non-blocking, and I've never seen it be an issue when profiling. > disabled my fancy modeline and show-parens This also would make no difference for me. > Prefer built-in packages like flymake to third-party ones like flycheck. Based on what benchmarks? Generally better to just not use external packages if they are causing slowdown (e.g. potentially git gutter, poorly written dired packages like dired-all-the-icons, weird interactions involving display alteration packages like adaptive-wrap, etc.). Profiling makes the problem obvious and should be the first step. [explain-pause-mode](https://github.com/lastquestion/explain-pause-mode) is also worth mentioning. It's generally best to get as recent an Emacs version as possible (e.g. child frame performance used to be garbage, we now have native compilation and json parsing, etc.). Native compilation pretty much solved performance issues for me. > Increase the GC threshold and set it to run when you tab out or go idle Some people also like [gcmh](https://gitlab.com/koral/gcmh) and disabling GC in the minibuffer, which is what Doom does.

Thanks for sharing some information on helping tuning emacs performance. And an interesting setup to garbage collect on focus out, using `focus-out-hook`. However, do note that `focus-out-hook` is a variable defined in ‘frame.el’ and in its doc string reads: >This hook is obsolete; see ‘focus-in-hook’. > >Depending on timing, this hook may be delivered when a frame does in fact have focus. > > Prefer ‘after-focus-change-function’.

Also worth mentioning that getting the latest version of emacs isn't necessarily enough to get native compilation. Arch Linux and FreeBSD both have native comp disabled in their Emacs package. Arch Linux has a separate package for native comp and FreeBSD has an option you can configure when building the port. Idk about the other operating systems.

That's bizarre. I've been using a script to change the emacs-git pkgbuild to use native compilation and lucid (because of the notorious gtk bug) for a long time so I didn't know it's still not the default on arch. Emacs-plus on osx can be installed with native comp. On windows, I just have a script that clones/compiles Emacs in wsl.

Wait, emacs-git doesn't have native comp but it does have pgtk?

emacs-git is an aur package, not the official arch linux package named "emacs". I don't know what the various aur packages have enabled.

> It's hard for me to imagine anyone going back to linting on save I have - I find the constant commentary on what I'm typing to be a distraction. Completion suggestions are enough distraction already, I'm even thinking of turning them off too.

Oh sure, my bad.

IIRC, there was a point Flymake didn't perform too well compared to Flycheck. But, again, IIRC, I think Flymake has been given a few updates and due to native-comp and Flymake being built-in it does a little better(?) than Flycheck. Granted, Flycheck makes it easier to create checkers. But [flymake-collection](https://github.com/mohkale/flymake-collection) and the [macros it defines](https://github.com/mohkale/flymake-collection/blob/release/src/flymake-collection-define.el) make it easier for Flymake. I could be talking out of my ass, but that's what I remember hearing and seeing.

why not tagging this under "Emacs-fu" instead?

Exercise extreme caution in following the advice to raise the GC threshold. There be dragons, depending on your system's load and memory pressure outside of Emacs.

> I find the constant commentary on what I'm typing to be a distraction. Me too! Cognitive overload abounds, I like to be left alone to think and trigger these things when I want them.

This right here. IDE features need to shut the hell up until I've finished a sentence, then you can nitpick me.

Constant commentary and linting on save are not the only two possibilities though. Unless you really only want linting to be shown manually, I don't understand why you would want linting on save (unless you already auto-save on a longer idle period). > Completion suggestions are enough distraction already, I'm even thinking of turning them off too. This also sounds like a configuration issue (increase idle delay and/or minimum prefix length and/or start using completion more often rather than manually typing longer symbols). Why manually trigger things when you can just have them trigger automatically in a way that is more intelligent/better fits your workflow? Some configuration or code may be required, but it's not all or nothing.

Thanks, very informative. Will try those packages. > You're talking about linting? It's hard for me to imagine anyone going back to linting on save... I can't imagine this being a significant source of slowness. It's non-blocking, and I've never seen it be an issue when profiling. Yep, it made a huge difference for me. > This also would make no difference for me. Weird, disabling spaceline was a significant improvement. I tried other modelines as well, and the lag was noticeable for all of them. I ended up writing my own minimal modeline that does lazy evaluation (i.e. only on save) of the number of lines in the buffer.

[removed]