Why is Doom Emacs So Slow?

I'm unable to understand this. I just installed a fresh copy of doom emacs. I haven't changed anything other than enabling a few languages in the init.el file.I am coming from VS Code and honestly, the experience is just worse. Emacs is laggy as hell. Opening a file is laggy, code completion is laggy.I'm on Mac OS. My laptop is old now. 7 years+ but it does VS Code does work pretty well. No noticable lag anywhere and code completion is faster than emacs. What gives?

I cannot help for non-vanilla Emacs distributions, but I'd recommend taking a look at vanilla Emacs performance on your machine, just to be sure that Doom is indeed to blame as that will facilitate debugging and figuring out who can best help.

if you wanna help you need to post your init file.

Please post your emacs --version, Your OS version, and your type of storage. You have determined that Emacs as a whole is is laggy running a particular version and build of Emacs on a 7+ year old Mac. This probably means a 5 year old version of Emacs on a 10 year old mac with spinning rust vs a ssd. To maximize performance ensure you are running the most recent version of Emacs built with whatever options are ideal for Mac on an ssd.

Are you sure you have native compilation enabled? If you really just enabled only a few languages that's pretty surprising, and you might be able to resolve this by going into the Doom Emacs discord and posting some stuff. There's a lot of native compilation going on to make things work well, but at the end of the day it's a big project mostly maintained by a handful/one person who is just trying their best. You really might just be hitting some edge cases. Code completion.... might be an LSP mode thing. Depends on the language/project you're opening up. Eglot performs better in my experience. But there's a lot of stuff going on. If it makes you feel any better... VS Code hangs for me on some stuff too. LSP really changes the game for this stuff because some projects work totally fine but others will hit weird edge cases based on their dependency graphs or whatever but it will only affect certain access patterns. It's tough!

Make sure u r running the emacs daemon at start up:)

And run the emacs client under the emacs daemon ,instead of just running regular emacs.

I am. And I'm getting downvoted for a genuine issue lmao. I'm beginning to think Emacs community is in denial.

I'm doing both things correctly. I'm not talking about the Emacs launch time anyway. But the time it takes to load a file

I'm on Emacs 28.1 and I installed it via brew. The config file is the standarm doom My Mac very well has an SSD a small but scrappy GPU 3rd gen core i7. Also on the same machine, vs code just works. It ain't an assessment in vacuum. It's a comparison with VSCode. I'm really beginning to realize how much denial there is in the Emacs community. You do know that 7 years old ain't all that old for a good computer, right? I do 4k video editing on it and the latest version of blender works just fine.

I'd have to check about native compilation. I just installed Emacs via brew and then the doom config. The language I'm working with is react Jsx. More than that though this is the first comment that's actually trying to help. People are really bitter in this sub. Is this the community I'm trying to be a part of? No thanks.

in my brief experience with emacs, i have learnt that emacs has a ton of strong points but i need to let the code completion go. it is not emacs' strong suite(for me a noob). nvim has quicker/better code completion than emacs.

Can you reproduce the same performance issues on standard emacs? One point of order I have found performance of completion can differ drastically dependent on tools. One massive point is that how precisely completion is triggered can have a huge effect on perceived performance especially if a particular set of tools requires a lot more work based on tools or project. For instance something that is blazing fast when triggered at 1/10 of a second can be awful if it's constantly recalculating at every keystroke. Likewise triggering it on stopping typing requires an awkward pause that itself adds perceptible latency. In my opinion the only reasonable configuration is triggering completion upon pressing a hotkey as opposed to showing suggestions constantly or showing when you stop typing. Change that setting alone and see if it doesn't make a massive difference.

I have laptop with i5 6th and doom emacs works fine but doom emacs has alot wrong choices

Is it by chance on your work laptop ? My emacs is slow as hell at work (guess this is the antivirus or something). Whereas at home it is really snappy on a 10 year old laptop, both on linux and windows

In that case you likely don’t have native compilation available. Simplest way on macOS to get native compilation is my [emacs-builds](https://github.com/jimeh/emacs-builds) project. Emacs 28.x and later, including nightly builds all have native compilation, and are available as Homebrew casks. Alternatively if you prefer to compile Emacs on your machine, there’s [emacs-plus](https://github.com/d12frosted/homebrew-emacs-plus) and my own [build-emacs-for-macos](https://github.com/jimeh/build-emacs-for-macos) which both have options to enable native compilation for 28.x and later builds. As for the performance issues you’re seeing, based on the age of your hardware, I do believe native compilation will make a very noticeable difference. However on first start, it will be running native compilation in the background, which will eat a lot of CPU. Check for a async native compilation buffer to see the status of it. I don’t use doom emacs (or any config framework), but [my config](https://github.com/jimeh/.emacs.d) is generally very fast and responsive. Especially with things like language server interactions and completions in Go and such. Though it does depend on the language server. Solargraph for Ruby can typically be pretty slow or just act up, but that’s outside of Emacs’ control. Edit: Clarified language server performance varies between different servers.

What's the result of running `doom doctor`?

[deleted]

Well, you come in a sub of people who have been using a tool for years and years and Doom had been used by a lot and you just state that it's slow without providing useful infos to help you. You realise that if it's slow for everyone nobody would use it, right? So it might be an issue with your configuration. And the rest of the comments here are asking for more infos, not bitter, so I'm not really sure about what you're trying to show here

It's probably because you sound whiny and opinionated, even though completely ignorant. I don't even use emacs by the way, just tried it for a few weeks some time ago.

Howdy! Let me open with something I'd guess quite unpopular in here: I'd recommend to use VSC, if you feel that's OK for your needs. I personally tried it, and never went beyond the first attempts, because I like too much the way Emacs allows me to treat the various thing I have to do, and being able to move through shell traces from inside the editor is too precious for me. It shaped my working flow through the years, not to say that I love hacking in lisp. That said, and trying to come closer to your point: I'd first of all have a crack at some profiling system. First google match looks already interesting: [https://www.gnu.org/software/emacs/manual/html\_node/elisp/Profiling.html](https://www.gnu.org/software/emacs/manual/html_node/elisp/Profiling.html) Then, assuming you cannot avoid LSP, I'd try to be sure that the grammar descriptions used by VSC and Emacs are, if possible, *exactly* the same, or otherwise very quite equivalent (slippy floor here :)); that, in itself, is already a *reasonably* time consuming task (as you need to figure out what LSP takes as input as grammar descriptors, and whether VSC and LSP emacs module can get the same, otherwise...welcome to the grayland of untractable-to-undecidable problems), but if you want to compare apples with apples (which sounds even more appropriate on an Apple!) this is a quite necessary step. If instead you can avoid LSP, unnecessary if the language you need to edit sources in was already supported by some already existing emacs package/module, been out there for a while, then I'd recommend to consider switching to that: LSP is a wonderful idea for new languages support, and extremely convenient for parser developers intended to address a multi-editor audience, but decoupling front-end and back-end language parsing, even though clearing the language analysis picture, is reducing chances for optimizations, that, if your edited language is old enough, somebody else very likely already addressed and hammered for a while before you. If I got your other posts right, you're targeting react javascript. If my catch is correct, than Google comes in help here again, giving as top rated matches, AFAICT, at least 3 different solutions that, at a first glance, do not seem to use LSP. I stop here, as react javascript is not in my playground. HTH!

Could it be that the VSCode is able to be implemented in some more efficient libraries for your version of OSX? I mean than those libraries that doom emacs has to depend on. What about the performance of the vanilla GNU emacs? Have you checked that out and compared its performance to doom emacs as well as to VSCode?

I can see that this sub is for emacs fans. I suggest asking question in a non-complaining way, such as: what's wrong with the setup, is it possible to improve the performance of my doom emacs?

oh.. so you think a program should be slow on a.. 10 year old hardware? 10 year old hardware is monstrously fast - no text editor or lisp interpreter should be slow on any machine.

why are you downvoted is beyond me? what is this, a community of angry 16 year olds?

That doesn't get answers as quickly as this does. i lose 10 karma, I already got some good suggestions. Otherwise it'd get maybe 2 comments.

You're getting downvoted for making hostile comments like that.

[removed]

Lol xD... so you're actually doing some calculated moves for being provocative among supporters of emacs - and I expect the unfriendly reaction to your provoking mannerism should be part of your anticipation apart from the few helpful advices, supposedly from experienced users of emacs

A program will be slower on 10 year old hardware of similar value. I don't think that statement is at all controversial. An interpreter is by definition something which could be asked to evaluate a program of arbitrary complexity including ones which never terminate and ergo take an unbounded time even if run on an infinitely fast machine so basically your proposition makes not even the slightest bit of sense. Think that is too abstract? As part of deciding how to style text and offer suggestions on possible completions one has to perform the arbitrarily complex task of parsing an arbitrarily large amount of code. You wont see Emacs lagging while trying to enter the letter "a". However what you can see is lag if you ask it to character by character imagine what comes next while doing whatever else if the tooling that does this is itself takes long enough depending both on its performance and what you feed it. One solution to improve performance is to avoid making it produce an every changing list of completions as you type each character given the fact that you can easily produce 300-600 characters per minute.

Run `emacs -Q` and report back whether that is "laggy" or not. If not, the "lag" is happening somewhere in your config. Doom is an enormous config, AFAIR, so it might take time to narrow it down; but firstly make sure that it's not something more fundamental by testing with `emacs -Q` (and if you get bad performance from that, then no config is going to improve matters; but also there's likely something wrong with the build of emacs that you're using in that case, so almost certainly some alternative build is going to work better... I believe there are many different MacOS builds, so do some research.) If you need to track down slowness in your Doom-based config, others have mentioned the "doom doctor" facility, and more generally Emacs has a built-in profiler which may help. Failing anything else, you can use the recursive bisection technique on your config to track down what is responsible.

I imagine the main thing is your phrasing implies the stuff is inherently slow rather than leaving open the possibility of mistakes on your end or something else. And not providing much actionable information. Text chat is tricky, try not to take it too hard (and yeah honestly I think people are not being very generous here. Maybe lots of people are having a bad day)

I tried vanilla Emacs + doom Emacs-macos + doom (this was just sooooooo much worse) The latter was supposed to have native compilation but I can't know for sure. Gonna tinker some more.

Out of absolute curiosity try to run it in the terminal vs as a GUI. I had this issue recently and the fix was to update both my MacBook and Emacs and now it's fast again. I use auto complete and a whole host of other things. Though I do not use Doom.

[deleted]

i mostly use Emacs on Windows, but i also have a MacBook and a Linux desktop (Fedora). Emacs runs so fast on my old MacBook, a 2012 13". I'm not in denial—it's the truth! i use GNU Emacs on all three major OSes. i even used it on a FreeBSD VM and a OpenBSD VM a year ago, and it also worked well there too. I'm not lying to you when i say that Emacs is fast af. it's lightweight and fast. for massive files, VSCode and Sublime Text are better. for pretty much anything else, Emacs **smashes** everything else. just **SMASHES**.

It is almost impossible to help if you do not share details. Describe “laggy”, describe the environment, share your doom configuration, maybe even record a video showing the problem, etc. I am running Doom emacs in a 2013 MacBook Pro (i5 2nd gen I think) without problem.

Do you know what is even faster? “I am willing to pay/fund a developer to solve my issue”. Remember, this is an open source community built by volunteers.

Not denial. My machine is much worse than yours and Doom runs fine. There's something wrong with your environment.

Your posts are not friendly either. Nobody here can spoon feed you and you seem to be very much more motivated to bash Emacs rather than to search for a solution. Ask specific questions instead of writing: Why is Doom Emacs so slow? Nobody can help you if all you do is to complain. Help us to help you or give up and switch to whatever you think/feel is faster for you.

If the later had native compilation, it could been performing native compilation in the background, which does make everything slow as it uses a lot of CPU for it. Once native compilation is done however, there should be a noticeable improvement in response times for keypresses that invoke lots of elisp functionality, like code completion, and more. I’d be happy to help you debug things a bit if you want :)

Check if the emacs version you have installed is the most recent one 28+ by running "emacs --version" If it's 27 or lower, google how to install emacs 28 in your system. Next disable some plugins like the indent guidelines (these kind of plugins are sometimes laggy).

I had same problem with you. But i rewrite my doom emacs configuration and my problem was solved Check this link This is my doom emacs configuration [https://github.com/alishahidi/dotfiles/tree/main/.config/doom](https://github.com/alishahidi/dotfiles/tree/main/.config/doom) Read the config.org file to better understand my config

Haven't you learned yet the iron law of open source community support? If you go onto an IRC channel or forum for a piece of open source software, say Linux, and ask "how do I do X in Linux", you will, politely or impolitely, be told to RTFM. If you say "Linux sucks because you can't do X", people will fall all over each other to nerdsplain that yes, you can do X, and it's real easy too, all you have to do is...

If native compilation is what is missing then Emacs must be slow. Emacs has been around way longer than VScode and if it requires native compilation which is a new feature to be on a par with VSCode than it is slow. Emacs is customizable and offers many features in addition to code editing and if you are interested in such things then it may be the thing for you. But if just editing, debuggging and compilling your code is your main need then just stick with VSCode.but

> If native compilation is what is missing then Emacs must be slow. Elisp has never been known to be fast and contributions to change that have been welcome for the last few decades. Native compilation is the most recent one, because for the most part people preferred to just use external programs to do heavyweight stuff rather than improve Elisp (partly because that requires a different skill-set as well), which is why so many modes rely on external programs written in some other native language with high-quality optimizing compilers like C has. > if it requires native compilation which is a new feature to be on a par with VSCode than it is slow. VSCode is *also* slow and that's with native JIT in its scripting engine, because for some strange reason the devs decided including a whole browser engine it in it as well was a completely reasonable and desirable design choice (despite it offsetting most gains from their otherwise pretty performant JS engine). I beg to differ.

> I'd recommend to use VSC At least recommend [VSCodium](https://vscodium.com/) rather than actual spyware.

Any interpreter will be slow on any machine (excluding shenanigans like JIT, which involve some native compilation). There's a reason native compilation is a thing and why most performant Common Lisp implementations are compiled to native instructions. A 5 or 10 y.o. Emacs will not have native compilation, which would make a large difference. I'm not sure it would even have some of the newer improvements to the bytecode format that *also* improved performance (some but not all of them related to the implementation of partial lexical scope). [Here's an article that mentions some interesting bits about Emacs' internals and bytecode performance](https://nullprogram.com/blog/2016/12/11/) (it also references other articles that go into further details).

> > > One solution to improve performance is to avoid making it produce an every changing list of completions as you type each character given the fact that you can easily produce 300-600 characters per minute. To continue this, some other solutions which have been implemented by various means involve asynchronous computation and parallelism to ensure the interface doesn't jitter nearly as much.

There's an immediate resort to ad-hominem co-existing with an apparent unwillingness to perform analysis of Doom's performance or other profiling steps, which is understandably seen as rather unreasonable. It is quite possible that there is something either in Doom, the specific Emacs build or OSX which greatly and negatively affects performance in this case. A similar scenario was seen with git which for the longest time (and it might still be the case - I haven't checked) simply [performed extremely poorly on Microsoft Windows' filesystems](https://stackoverflow.com/questions/19591925/git-has-huge-performance-issues-on-windows). The root of that issue has to do with both [the functioning of system calls in Windows](https://shellbombs.github.io/Windows-Performance-Toolkit/) and the way the filesystems are designed.

Quite correct but as a user unless you are inspired to roll up your sleeves the sane solution is to configure your tools in a way that they don't perform poorly. The assertion seems to be that Emacs as a whole is laggy which really isn't correct. The actual fact is that Doom Emacs a pre-made configuration framework is laggy when configured to provide continual completion suggestions when used in combination with tooling and/or codebases wherein such suggestions take too long to generate. Emacs doesn't default to such a configuration and cannot inherently fix for example doom doing so or its usage in combination with tools that will predictably perform poorly given current facts on the ground. Doom is neat but it doesn't eliminate in full the need to configure your tools correctly.

Indeed, the bit about asynchronism/parallelism that I mentioned is more how some modes have implemented it than something user-facing. Proper configuration matters for certain.

OP posted the same thing in r/vscode with the names reversed. Just a troll.

The Emacs one was genuine, although I did some tweaks and now it works fine so I switched. But I did realize that the Emacs community was crybabies though so I wanted to see if VSCode people are as insecure or not. So far they don't seem to be. In the end I'm gonna edit both the posts and add links to each other as a social experiment.