native compiled emacs!

I'm pretty late to the party with this but just installed it last night on an old 2015 8bg ram macbook and it's amazing. I had to stop using emacs for what I do because the lsp's would just create so much lag and ivy and magit would also just hang and take really long. Seems all this is now gone just as I was getting used to another editor I won't name. Anyone else using this full time and is there any hidden surprises I'm not seeing yet as I'm a bit skeptical of this at the moment?

No matter what, an LSP is still the only thing that slows me down. Especially if the file is moderate to large in size, or I have many files open in the workspace. If you can live without the features that call for changes with every cursor move, you will feel less pain. This from a JavaScript developer via the typescript language server. Thankfully I am not too reliant on an LSP and can often leave it off.

I’ve thought about turning it off many times but my issue is I do 2-3 languages an my brain just can’t hold onto things. Maybe I should look into toggling it on/off

What did you do before MS popularized the language server?

I remember using tern but I think I had issues with it but I honestly can’t remember I could have switch because of hype as well. I changed to a mobile stack and have just recently returned to web so just getting back into this side of it again

That problem is not really LSP (mode) but the ts-ls language server, IMO. It has exactly the same issues in VSCode where things freeze often for long time.

That’s actually quite nice to know that

> LSP is still the only thing that slows me down. Have you tried an alternative LSP implementation? Check out [ycmd](https://github.com/abingham/emacs-ycmd) and see if it works faster for you.

Don't know if you've tried [lsp-mode's performance tuning tips](https://emacs-lsp.github.io/lsp-mode/page/performance/), they seem pretty useful. Or if you use eglot, make sure to set eglot-events-buffer-size to 0 to disable event logging when you don't need it. Event logging is extremely slow because it's logged with pp-to-string :(

> No matter what, an LSP is still the only thing that slows me down. You should try writing more macros. ;) When stacking up a bunch of bulk operations you really get a feel for the number of things per second your editor can do.

Yes, I am using LSP with Python and C++ and neither of them freezes or blocks e.g. syntax highlighting for long time like the Typescript server. E.g. you save a file - but the diagnostics doesn't update for 10+ seconds. Sometimes completion takes ages, etc. And colleague who uses Typescript in VSCode has exactly these same issues with it (both VSCode & Emacs use the same Typescript language server, AFAIK).

I had the same experience when I first got a native-comp enabled build working on macOS two years ago. It made a night and day difference, a few months earlier I had started wondering if I need to give VSCode a serious try thanks to performance issues I was having with Emaxs. So native-comp came at the perfect time for me. As for issues related to native-comp, I’ve personally only ever had one related to an actual bug in the native-comp code, but Andrea was responsive and fast to fix it. This was back in the early days though long before native-comp was merged into master. I think the worst possible thing that can happen thanks to native-comp now is basically that a package fails to compile to native code, which is possible but rare, as native-comp is a little bit stricter than byte compilation. But in such a case, the worst that happens is a warning message, and the package runs as pure elisp, or as byte-compiled elisp instead of as native code. Others have mentioned lsp-mode as a performance issue, but I find it mostly depends on the language server. Go’s gopls server is pretty much always instant, Ruby’s solargraph is a bit of a hit and miss, and the official Terraform language server is very slow and questionable most of the time, taking as much as 5 seconds to respond at times.

Yeah mines is tuned with most of it off to be honest except the completions and indexing stuff. I mean currently it’s not a problem anymore due to the native comp but I’ve not had a change to get loads of buffers and errors to see if it has a breaking point etc. hopefully it’s fine

I've been using it for months, and I've seen absolutely no problems.

I have written a couple of macros for my own init but it's debatable as to whether or not they could just be functions. Would you be willing to share what you have managed to do?

I have achieved all of the green check-marks for lsp-doctor, and ended up moving on to eglot just so I wouldn't have to keep trying to coerce lsp-mode to respect the nearest git root. I will be trying that buffer size setting :) Even the almighty (Neo)vim stutters at the sight of a large LSP watch buffer, so I get what you mean.

I believe they were referring to keyboard macros rather than lisp macros. (Although writing lisp macros *is* liable to slow a person down :)

When I cared a lot more about code completions, You Complete Me kept me in Vim for a while. Sad to see it's not popular enough to maintain on Emacs. It's good that we have an open standard for grokking new languages now, and even better that Emacs has the ability to implement that in a usable way. My hang-ups with LSP are most just my pickiness. I am sure others aren't so bothered by stops and stutters for what they get in return from things like lsp-ui.

I've been using the nativecomp branch for a pretty long time now—forget exactly when I switched to it, but it was well before it was officially merged/released. It's been a massive improvement with no real downside. I disabled deferred compilation in favor of compiling all my packages ahead of time and that does increase the compile time a bit wherever I upgrade but it's not too bad and it means the experience when I'm *using* Emacs is exactly the same as it ever was except snappier.

No surprises it is just great!

Using it on all my computers (well, almost*) and loving the performance increase. It works great and I've never had an issue. *I haven't looked into how to get it working on my school pc, which is the only pc I have that runs Windows. I probably should, though, as it needs better performance.

LSP is not working for me, no matter the editor, takes a lot of RAM, makes faulty warnings and can't find symbol definitions. I'm usually working with nested GIT projects with many thousands of files. VSCode says it's too many files for it to track changes and it is dog slow and won't let me have enough simulatenous open buffers, PHPStorm will take a 30min just to index the project and by that time I could have finished the job and gone over to the next

I am using LSP+clangd on a project with 25,000 files and I don't have any issues. My GC threshold is 1GiB😁. Not sure whether it is helping it. I remember before this GC setting it used to hang-up for several seconds.

I use native compiled and I am loving it. Noticeably faster. I pretty much use the same packages you mentioned and some more for Lean4, Scala, and few others.

Take a look at lsp-bridge. It uses python threading to handle lsp requests, very fast.

sounds like u might need to exclude some directories or files from indexing or any kind of scanning. I remember what helped me a lot on an Angular project was to not index the node_modules dir. and later we switched to pnpm, which only links to modules in some single, per-user directory, so when the same module was used in different projects/subprojects it didn't have to be processed multiple times.

Ok I'm usually working in projects with 100,000+ files and I have about 20 such projects and need to switch between them quickly. LSP does not fit my use case very well perhaps

I hope you are using something like projectile to manage the different projects. I think LSP launches a separate clangd process in the background for each project, so the bottleneck is going to be CPU & memory as clangd keeps the indexes in memory AFAIK. P.S. Oops. I just assumed you are using C/C++. If it is some other language, then clangd is not involved, but the respective LSP implementation for that language. The bottleneck is unlikely to be emacs or the lsp client.

no I don't use projectile, it does not work with nested GIT repos either and I have not found a use case for it. Anyways I am happy and productive without LSP in my life at the moment. Another issue with LSP is if you have different language versions for different projects you need to spin up a separate server for each project and then there is the dependency hell of making it work and keeping it working overhead time