make emacs run 100% faster and snappier

crying about emacs being slow and laggy ​ add the following packages and their setting in your config: ​ automatice garbage collection on idle [https://github.com/emacsmirror/gcmh](https://github.com/emacsmirror/gcmh) ​ make lsp lighter and faster [https://ianyepan.github.io/posts/emacs-ide/](https://ianyepan.github.io/posts/emacs-ide/) ​ is your emacs blinding white. Add the following package in your config and their settings: ​ add a darker theme to emacs [https://github.com/doomemacs/themes](https://github.com/doomemacs/themes) ​ optionally: you can try out gccemacs which has native compilation if you are on any linux distro ​ [https://www.emacswiki.org/emacs/GccEmacs](https://www.emacswiki.org/emacs/GccEmacs) ​ General advice: ​ set the value of gcmh-high-cons-threshold to a suitable value of your choice do not set it to very high values as it will not have any performance gains acorrding to the below post. minimum value if you are an lsp user "100000000". ​ [https://bling.github.io/blog/2016/01/18/why-are-you-changing-gc-cons-threshold/](https://bling.github.io/blog/2016/01/18/why-are-you-changing-gc-cons-threshold/) ​ Also do not set the value of gc-cons-threshold value in lsp package :config option as this value is set automatically by gcmh package ​ never turn your back again to emacs. emacs is awesome!!! :) ​ NOTE: ​ The above post is not to cause fights or to raise any political agendas. This is just an opinion and help by myside to any user struggling with emacs performance issues.

Have you tried using an emacs server and client combination?

Yeah i am currently using it and after doing the above works really great

gccemacs now also works on Windows and macOS system, not only Linux.

> is you Emacs blinding white? turn your brightness the fuck down! ;P it's a lot easier, than trying to make everything dark themed... plus it's more readable too. I've noticed how people with dark themes complain when they open some web page, - which is 90% likely to be light themed -, that it's blinding them. one reason is the sudden raise in the amount of white on the screen, but the other reason is that they crank up their brightness, just so their dark theme becomes readable enough...

The proposed settings of the GC threshold are too high and thus potentially dangerous. Caveat emptor!

As a heavy dark theme user, I have also noticed that high brightness is still an issue. With light theme its very apparent when brightness is too high/low and obviously hurts your eyes. With dark theme, its less obvious, but I'd noticed i had eye stain when looking at dark mode stuff for a while that went away after lowering brightness to the same level as was comfortable with light mode.

Is there a pre-built installer for Windows? I don't think I've got the time or patience to collect all the dev packages and build it myself!

I don't know much about it but i have heard from a lot of people like if they set it to a really high value then you have a slow emacs startup and if you set it to really low value then it lags and also the lsp performance page do specify to put a value if around 1 mb or higher and also the gcmh package maintainer says by default they have a really high value set to gc-cons-threshold variable so i think there should be some middle value which is ok i would say.

Is GC even still a thing when running with all elisp native compiled?

GP has been known to harp on users' "overclocking" of GC thresholds. There was a time when I heeded GP, but as my familiarity of GC grows, I've concluded GP is guessing like the rest of us. Having seen the gcmh author's code and remarks over the years, I'd give his opinion more credence.

Yes. Native compilation makes the elisp faster, but it doesn't turn a garbage-collected language into one with memory management like Rust or C. (Rust still has memory management, it just inserts allocations and frees for you most of the time. A value that goes out of scope in Rust will have its destructor called *right there*, as opposed to in elisp where the destructor will run at some point in the future.) The compiler might be able to notice that a particular value never escapes a certain scope and thus can be destroyed immediately, but that's veering into "sufficiently smart compiler" territory.

This unnecessarily high brightness is an issue since the dawn of the TV. People were coming up with rules, like don't sit too close, don't watch for too many hours, etc... They preferred superstition over science... My father thaught me to pay attention to the brightness, so I've learnt it at a very early age of about 10, in 1987, to dim monitors according to the lightning conditions. and this applies to your phones too, ppl! it's so accessible on iPhone/iPad and most Android devices to control the brightness, no excuse not to use it and take better care of your eyes!

That’s like your opinion, man. A light theme is not inherently more readable than a dark theme. Most developers prefer a dark theme, so you’re in the minority.

It’s being worked on, yes. The native-comp feature is not yet released (it’s currently on rc3), and there are some refinements to deal with the various things meant by “Windows” (msys, mingw, Cygwin, etc). You can try the bleeding edge here: https://git.sr.ht/~mplscorwin/emacs-w64

Native-compiled elisp still needs to dynamically allocate memory. How would you expect that memory to be managed? Lots of languages compile to native code and still use garbage collection, including common systems languages like C, C++, C#, and Go, as well as functional languages like Eiffel, OCaml, and Haskell. The two things (native compilation and garbage collection) are orthogonal. Hope that helps!

I don't want to turn this into a conversation about themes, but once switching to Zenburn, I've not been able to find anything else bearable to look at. Maybe I will try solarized-light again.

only true programmers use Dark Themes :P (/jk ofc)

of course it's my opinion... :) but I'm not convinced that it's a purely subjective question. I'm just trying to entice ppl to think a bit more and look into deeper causalities and do some self reflection. I've noticed this ignorance towards brightness setting, so I'm trying to raise awareness. > a light theme is not inherently more readable then a dark theme. this sounds very logical and most likely to be true, but why? > most developers prefer a dark theme 1. assuming it's true, then it contradicts to your previous statement, suggesting that dark themes are actually inherently more readable. 2. how do you know, that most developers prefer dark themes? 2a, maybe such preference changes over a lifetime 2b, maybe new developers just copy their teachers 2c, dark mode became a trend over the past decade. I remember when one reason for using dark mode was to reduce the power consumption of LCD displays, because laptop (or as they called them back then: notebook) batteries were quite shitty 2d, maybe it's just a diversion from more important problems, like the flying duck in battle chess :) 2e, maybe because many (vocal ;) programmers -like myself- have ADHD, which indirectly results them being up late, when a dark theme is more usable (or beneficial, because it doesn't disturb their partner's sleep :)

[deleted]

Yes. You can download Emacs 28.0.92 or 29.0.50 from GNU official website: [https://alpha.gnu.org/gnu/emacs/pretest/windows/](https://alpha.gnu.org/gnu/emacs/pretest/windows/) But you need to install `libgccjit` by msys2, put it in your PATH. And it will works.

Sure it is, but I've been using it for several years - never got any related issues

That lsp post recommends turning off a bunch of features to speed up lsp and reduce clutter. Which of these actually speed things up (as opposed to just reducing clutter)? (setq lsp-enable-symbol-highlighting nil) (setq lsp-enable-on-type-formatting nil) (setq lsp-signature-auto-activate nil) (setq lsp-signature-render-documentation nil) (setq lsp-eldoc-hook nil) (setq lsp-modeline-code-actions-enable nil) (setq lsp-modeline-diagnostics-enable nil) (setq lsp-headerline-breadcrumb-enable nil) (setq lsp-semantic-tokens-enable nil) (setq lsp-enable-folding nil) (setq lsp-enable-imenu nil) (setq lsp-enable-snippet nil)

It is fine to do that for yourself, but others should be careful to copycat that, because their situation and system configuration could be very different. That is why I'm not a big fan of advertising such settings: you never know what trouble you could cause to someone who doesn't necessarily understand the fine details of GC in Emacs.

> I don't know much about it but i have heard from a lot of people like if ... I am sorry to interfere, I don't really have much to add here, but a small remark: would you rather listen to what you heard from someone who heard from someone or would listen to *the* source? Here is the Elis recommendation, for your convenience: https://www.reddit.com/r/emacs/comments/sunkzx/is_it_only_me_or_did_emacs_without_native_comp/hxljaym/?context=3 That seems like a sound advice, and I am quite sure EZ knows what he talks about.

> automatice garbage collection on idle Emacs already does that when possible. > add a darker theme to emacs There might be reasons why to prefer a lighter or a darker scheme, but the speed is certainly not one of those. If Emacs lags, it certainly is not your screen not being able to render white, or yellow or whichever color pixels. > you can try out gccemacs which has native compilation > if you are on any linux distro You can try it out on MS Windows and Macos too.

Why are you writing a thesis? It’s a personal preference. People can formulate that on their own, and a color scheme has no bearing on anything. Why are we still talking about this? Edit: I’m not going to lie: I really couldn’t be bothered to read your thesis. Sorry.

Agree. Light themes are almost always better, people just need to turn their monitor brightness down, even more so if they're the type to sit in dark rooms.

TLDR: you contradicted yourself.

Cool. I really care - like so much. It’s crazy how much I care.

> Learn how to be wrong & how to be right. Be decent. Be nice. Be cool. — https://mobile.twitter.com/novasenco Assuming it's you, your tagline suggests, that you might care... Sorry for the disturbance. Peace.

Peace

I simply refuse to read a thesis about ……. Preferences of color schemes. I guess I just don’t care enough to find out how I contradicted myself about …….. color schemes. Woe is me.

Prot has been just given the "Outstanding New Free Software Contributor" award. His main work is the Modus Themes (https://protesilaos.com/emacs/modus-themes), which is entirely about color schemes. Indirectly, it's an example of the manifestation of software freedom too, as we could learn from his videos. It think color schemes has more bearing on things than you proposed. https://www.youtube.com/watch?v=27IuHHGKknI

Probably. That’s cool. Good for them.

But also trying to convince others that light color schemes are “better” seems silly goose to me (cuz personal preference is a thang with an ‘a’)

As someone who definitely prefers light themes (plus Redshift on the desktop) I still find most light themes I check out to be ugly and/or garish. I do like the [faff](https://github.com/WJCFerguson/emacs-faff-theme) theme though, which is *extremely* mellow. It's kind of uncool, but comfortable as hell in day or night. I feel like it's the socks + sandals of themes ;).

> A light theme is not inherently more readable than a dark theme. AFAIK it's been well measured that reading speeds are higher with dark text on light backgrounds, so it's more of an objective fact than just someone's opinion.

I think I could enjoy this theme. Thanks

Oh you’re so right. I’m converting to light theme now and everyone else should too so we can read faster and be more productive. Dark themes suck! Down with dark themes. I feel so edgy.

Yeah, don't what's it about zenburn, it's not even pretty but it's the most clear less straining theme for my eyes.

This reaction is uncalled for and exaggerated.

‘Cause it’s a joke that utilises irony in a way that tickles my fancy

I like to swim across the ocean instead of taking a plane. I get there either way, so it's really just a personal preference which one is better.

I know. I meant that it comes across as overly cynical for no reason which is why I said it was exaggerated.

I know. That was the point. It’s all preference.

Eggzaklee. This is the best parallel I’ve ever read. You’re so intelligent!

Huh? I'm not sure if I'm understanding you right. Why would you think Eli Zaretskii--Emacs maintainer of many years--is guessing? Why would you give the author of gcmh more credence than an actual Emacs maintainer?

[deleted]

Thanks for the chuckles

A necessary but also, in the case of unpaid positions, sufficient criterion for being a maintainer is time, of which, as near as I can tell, the current one possesses in spades. Time is independent of judgment.

Sorry, you're going have to explain more thoroughly and in different terms because I have no idea what you're trying to say.

He's saying EZ's incompetent. Hope that clears things up for you.

Your preference is fine. Nobody attacked it :). He was just pointing out that it was actually studied scientifically so it is not actually just preferences even if in the end the choice is your freedom. I understand being defensive but I don't think anybody was trying to offend you.

Wonder who they studied - not developers surely

I like irony

There isn't a physical difference between a developper and another normal human being. That said, the results of the tests were that for actual reading, black text on white background is less straining as the iris doesn't need to open as wide because of the higher surface of white. Black on white makes the eye work harder because of the much smaller quantity of white. This also explains why the white text can get blurry or "bleed" at times (halation). It can be worse if you've got a condition like myopia. That said, this is about comfort and eye strain. When it comes to efficiency, black on white has been proven to be faster for proper reading but white on black was shown to be better for scanning, which I'd argue is more relevant for programmers (you scan code blocks more than you read most of the time). So I'd say it's about what your priority is. In the end the best principle to keep in mind whether you go for one or the other is having enough contrast but not going towards the extremes (for example if you really have to pick white and black, go for a dark grey and an off white).