Declaring bankruptcy, OR: why is VSCode so much faster?

So I opened up VS Code for the first time in a long time. There was a file I wanted to edit outside of my normal project, and sometimes I like a separate editor for that so it's not polluting all the buffer lists and whatnot I have open. I saw that the clangd integration was available, so I turned it on, and I opened one of my normal project files. Why is clangd integration in VSCode so much faster and less painless? It came up with completions right away. I didn't have huge stalls while I waited for things to happen? I can only guess that something is weird with my setup, so I have to get rid of everything and start over, I think. I'll start with basically nothing except keybindings and eglot and p4.el and see if it's any better, because right now this is insupportable. The clangd integration in VSCode is faster than any code completion in Visual Studio or Jetbrains Rider, even with indexing turned on. I'd thought my stalls were because of clangd itself, and the absurd number of files it had indexed, but it's really not. I don't get symbol lookout timeouts in VS Code. There's something else afoot.

You don't have to get rid of your entire setup just try and find out if there is something in it that hurts the performance. Start out with just the clangd integration to verify that this gives you expected performance. As for why there might be a difference is esse of use and/or performance one of the simplest explanations might well be that someone has spent a lot of time to make it very good in vscode and that might not be the case for the Emacs package.

From what I can tell, Eglot really is a very nice, lightweight package. I'm going to bite the bullet and try to set up lsp-mode again, and the other lsp system that has a bunch of external dependencies and see what's actually performing best.

I noticed a significant boost in reliability and performance (in exchange for less-fancy UI) when switching to `eglot` and `xref`. It’s not quite as stellar as VSCode’s integration, but it’s reliable and fast and works over TRAMP. But YMMV. Good luck, and let us know how it goes. Be sure to run an Emacs with native compilation enabled.

Emacs 28 with native compilation?

You should start by profiling before writing the essay.

Emacs 29, using doom Emacs, I don't think it's as fast as vscode, but it's on par. Honestly having built my neovim config from scratch, I personally believe maintaining your own "flavor" if emacs is a time sync. A distro provides some very sane defaults which you can build upon or modify to match your workflow

Profile. Most likely you’ll find a nasty :eval in your mode-line 😆

> Why is clangd integration in VSCode so much faster and less painless? It came up with completions right away. I didn't have huge stalls while I waited for things to happen? I personally don't experience any hickups for completions and jumping around, but it would depend on the project size I guess. By the nature of VSCode vs Emacs, Emacs has (probably) much more work to do than VSCode. Clangd sends away parsed data as json, Emacs has to ocnvert that into usable lisp structures that Emacs use to display completions and jump round with xref etc. VSCode probably does not have to do as much translation for its internal structures, since they can probably use json produced by clangd directly. I don't know, I am personally not familiar with the implementation of VSCode, but I guess they would be stupid if they didn't designed VSCode with LSP in mind. Even if Enacs converts data in a low level C library (libjansson), if the project is big and there is lots of data, I guess Emacs has a bit more to do compared to VSCode. Obviously json choice was made in order to make lsp work over the wire, and probably with the javascript applications specifically in the mind (vscode :-)).

I've been digging into what looks like a similar issue - as far as I can tell this looks like a problem with the underlying way that emacs handles state updates. vscode's internals are mostly separate from the rendering process, while emacs' directly renders state at all times - this means that if there's any behind-the-scenes loading, it will happen first, then state is rendered. This is problematic with syntax highlighting (font-lock mode) because it happens 'live' as new lines of code are added. If you run profiler, you'll likely see that font-lock (aka syntax highlighting) eating the most cpu cycles - this is the cause of the lag. tl;dr - vscode is designed to do lazy syntax highlight rendering while emacs is designed to actively compute changes before rendering syntax highlighting. edit: not sure if 'designed' is the right term, but I hope it gets the point across well enough.

I find that whether or not a weird LSP will work at all kinda depends. Eglot hasn't been faster han my lightest lsp-mode setup, but it handles project roots way better. Trying to get Eglot to run Ruby Solargraph on the otherhand is not straight forward. I have lsp-mode ready to un-comment when I don't feel like jumping through unpaid debug hoops

>A distro provides some very sane defaults which you can build upon or modify to match your workflow Doom I've found is absolutely great for this, mostly because you can turn on or off pretty much everything, while still having sane defaults and being very fast (at least for emacs :P)

It doesn't have to be a problem with your setup but just limitations of Emacs, your OS and your hardware. In my case, under Linux with Intel UHD 620 driving 4K monitor, lsp-mode is just unbearably slow, while VS Code works fine. Profiling shows that most of the time is spent on font-locking and displaying the screen. Wayland and X11 are similarly slow. On the other hand, native Emacs under Windows or through WSL+X server runs smoothly. Reducing resolution under Linux also helps.

> If you run profiler, you'll likely see that font-lock (aka syntax highlighting) eating the most cpu cycles - this is the cause of the lag. There is a good chance that tree-sitter integration will help fix that soon-ish.

So this is interesting. At first I thought it might actually BE tree-sitter, but I added it back in afterwards and it isn't. But I think it might be a package I was using that tries to give each variable name in a file a unique colour. I haven't tested adding back in everything that I stripped out to figure out what the cause of the problem was yet.

I had tried profiling before, but I never got anything useful out of it. For instance, here's one: `1,958,132,691 63% - command-execute` `1,889,305,220 61% - funcall-interactively` `1,859,026,763 60% - save-buffer` `1,859,026,763 60% - basic-save-buffer` `1,858,646,825 60% - run-hooks` `1,856,209,743 59% - eglot--signal-textDocument/didSave` `1,856,014,573 59% - jsonrpc-notify` `1,856,014,573 59% - jsonrpc-connection-send` `1,856,014,573 59% - apply` `1,856,014,573 59% - #<compiled -0x1ae40cf16d13c42b>` `36,271,081 1% - process-send-string` `36,193,271 1% - internal-default-process-filter` `27,361,383 0% - #<compiled 0x1fa8af6bdbd6a339>` `1,649 0% line-beginning-position` `64,793 0% - jsonrpc--process-filter` `61,025 0% - jsonrpc-connection-receive` `36,889 0% - #<compiled -0xd98af4b9f55e46c>` `36,889 0% - apply` `36,889 0% - eglot-handle-notification` `36,889 0% - apply` `36,889 0% - #<compiled 0xfe0f1c02cdbdad7>` `23,888 0% + find-buffer-visiting` `11,840 0% + eglot--uri-to-path` `1,056 0% + eglot--check-object` `85 0% #<compiled -0x9de98e34fd5d35d>` `20 0% + eglot--range-region` `24,136 0% + jsonrpc--log-event` `1,056 0% #<compiled -0x1de56117c0c1b097>` `9,849 0% + timer-event-handler` `589,860 0% - jsonrpc--log-event` `378,616 0% - pp-to-string` `12,376 0% - pp-buffer` `12,376 0% + indent-sexp` `1,056 0% #<compiled -0x1de5613dbcf5f097>` `139,448 0% jsonrpc--json-encode` `105,954 0% - eglot--signal-textDocument/didChange` `84,666 0% - jsonrpc-notify` `84,666 0% - jsonrpc-connection-send` `84,666 0% - apply` `84,666 0% - #<compiled -0x1ae40cf16d13c42b>` `81,504 0% + jsonrpc--log-event` `20,232 0% - eglot--VersionedTextDocumentIdentifier` `20,232 0% - eglot--TextDocumentIdentifier` `20,232 0% - eglot--path-to-uri` `12,376 0% - url-hexify-string` `12,376 0% + mapconcat` `7,344 0% + file-truename` `21,816 0% + eglot--TextDocumentIdentifier` But stripping my .emacs down, and eliminating everything and slowly adding things back in actually worked. It was nice to see that it wasn't any of the helper code that I've written that broke things. My suspicion (which I haven't confirmed yet) is that the package I was using to give each variable name in a file a different colour was choking on things. But prior to using clang, I never saw these stalls, so that might not be it either.

It was honestly much, much easier to start from a very bare-bones position and add things back in. I stripped everything out, added lines back in that I knew were safe, tested, shut down, added back more things. I've culled a lot of code, and a lot of packages. Annoyingly, I lost my emacs customizations in the process (that is, my .emacs-custom.el file got empty data written to it) and apparently I wasn't backing that file up in git, so... Oh well, I've mostly got things back the way I want, and the practical upshot is that clang works as quickly as I expect it to. For a long time, I thought it was clang itself that was choking, because the project I'm working on is massive.

I would like to complain once again at how miserably bad the code quoting is now compared to before. This actually has nice formatting in every other web editor that can quote code.