6 ms·

My experience is that VS Code has a tremendous amount of input lag, to the point that I need to wait for a search prompt to focus before I can start my query.

My experience is that VS Code has a tremendous amount of input lag, to the point that I need to wait for a search prompt to focus before I can start my query. Emacs, on the other hand, is incredibly responsive, and even when running over a slow SSH connection has properly buffered inputs so I don’t need to wait. Emacs can achieve much more performant editing with the same server, so there’s no excuse for VS Code to be so slow.

BaculumMeumEst 3y ago
VS Code in its current state has no perceptible input latency on modern hardware, easily verifiable. If you invested the time to configure Emacs to mimic VS code's completion- instantaneous fuzzy autocompletion on every keystroke- the GUI would lock up every time autocompletion is engaged, i.e. the entire editor stutters on every keystroke, because the garbage collector is constantly blocking the UI thread. The performance limitations are widely known. It's the reason yyoncho, the creator of LSP-mode, forked Emacs to explore adding multithreading to address the issue [0]. But I can't see this being fixed anytime soon, because there are a fleet of intellectually dishonest zealots on the internet that refuse to acknowledge it's an issue, and will flame anyone who brings it up. As a result, when new users try out Emacs and see that the performance sucks, many of them will instantly uninstall and return to VS code, and the userbase suffers. [0] https://www.reddit.com/r/emacs/comments/ymrkyn/async_nonblocking_jsonrpc_or_lsp_performance/ https://www.reddit.com/r/emacs/comments/ymrkyn/async_nonbloc...
- G3rn0ti 3y ago
  > instantaneous fuzzy autocompletion on every keystroke- the GUI would lock up every time autocompletion is engaged, I am using lsp-mode enhanced autocompletion (using company.el) and I have never observed such a problem. I set the autcompletion delay to 0.0 in my case and work on 1k LOC modules. If you enjoy VS code, I am glad for you. It is certainly a good editor. But don't post generalized slurs against Emacs if you obviously haven't used it for long. Performance issues can happen but that highly depends on the context. What combination of language server, language server client and what language is causing this? Edit: If you are new to "lsp-mode" and you have performance issues, take a look here: https://emacs-lsp.github.io/lsp-mode/page/performance/#json-native-serializationdeserialization https://emacs-lsp.github.io/lsp-mode/page/performance/#json-... Also consider trying other LSP servers if available. For popular languages there are usually several alternatives to choose from: https://langserver.org/ https://langserver.org/
  - BaculumMeumEst 3y ago
    I mentioned that bringing up performance issues will bring you insults and dismissal, and you saw fit to reply with: > I have never observed such a problem > don't post generalized slurs against Emacs > If you enjoy VS code, I am glad for you. > you obviously haven't used it for long I guess it did not occur to you that you are immediately proving my point. To answer your question, the context is literally every single language server. Not only with autocompletion delay to 0.0, but also setting the minimum prefix to 1, so that it activates on every keystroke; the default is 3. The fuzzy completion cannot be configured out of the box, of course, it requires another extension. I posted a thread with much detail on why it occurs. You can downplay all you'd like, but a non-issue does not spur a productive maintainer to fork the entire codebase to implement changes, or alternative clients (LSP-bridge) that manage out-of-process connections to servers in order to work around Elisp limitations.
    - G3rn0ti 3y ago
      Well, Emacs has indeed a problem with blocking because it is single-threaded. To resolve that issue internally it also maintains an event loop being used to drive async. functions calls. But not all extensions leverage that yet. But I doubt the problem described in that reddit thread you cited is really caused by that. It sounds more likely the author of that Emacs fork experienced an issue with inter process communication. Who knows because there is no detailed context given. I am using "lsp-mode" for Javascript, Typescript (including React) and even on a huge Perl repository and I don't find it to be too slow for me. I am running a five year old mediocre laptop using Ubuntu. But perhaps I don't have the same standards as the author of that Emacs fork. > You can downplay all you'd like, but a non-issue does not spur a productive maintainer to fork the entire codebase to implement changes, or alternative clients (LSP-bridge) that manage out-of-process connections to servers in order to work around Elisp limitations. Well, it's an impressive feat, for sure. But I don't know anyone actually using that person's fork. So I wonder whether that really is such a huge problem as the author implies. And -- why do you care anyway since you seem to be happy using VSCode?
      - antoineMoPa 3y ago
- grgbrn 3y ago
  > VS Code in its current state has no perceptible input latency on modern hardware, easily verifiable. "easily verifiable"?!!? This is a ridiculous statement - lots of VSCode responsiveness is dependent on which language servers you're using, and some are definitely faster than others. Sounds like you're extrapolating from the languages that you personally use? The golang LSP has had widely documented performance problems on large codebases on and off over the past 2ish years (mostly resolved at the moment AFAIK), but it was severe enough that a large percentage of my group at work switched to Goland (Go IDE from Jetbrains) because it was much, much less laggy on our larger projects than VSCode.
- antoineMoPa 3y ago
  Not sure why you are getting downvoted, I think this is exactly the issue I'm seeing.
  - grgbrn 3y ago
    I didn't downvote this post, but I don't find it hard to see why someone would: * making incredibly general hand-wavy statements implying vscode is always perfectly lag-free and emacs is terrible * generally condescending and hostile tone: "if you invested the time.." "you saw fit to reply with" * some ranting and name-calling about a previous negative experience this person has had, which has nothing to do with anyone in this thread. (given the general tone of this post, i'd say there's a good chance that it was just this person deciding to abuse some unpaid emacs/lsp volunteer/maintainer and they rightfully said "go fuck yourself") * sadly, there is actually useful information contained in this post, but it's sort of structured as an inverse "shit sandwich" - some ranting and negativity, some useful and relevant information, and then more ranting and name-calling. which, i think, tends to mean most people are just going to ignore it or downvote. not really a constructive contribution to the discussion, despite actually having something useful to say
    - antoineMoPa 3y ago
      Yeah, makes sense. Parts of it resonated with me, but it's also a bit too rude.

BaculumMeumEst 3y ago

VS Code in its current state has no perceptible input latency on modern hardware, easily verifiable. If you invested the time to configure Emacs to mimic VS code's completion- instantaneous fuzzy autocompletion on every keystroke- the GUI would lock up every time autocompletion is engaged, i.e. the entire editor stutters on every keystroke, because the garbage collector is constantly blocking the UI thread. The performance limitations are widely known. It's the reason yyoncho, the creator of LSP-mode, forked Emacs to explore adding multithreading to address the issue [0]. But I can't see this being fixed anytime soon, because there are a fleet of intellectually dishonest zealots on the internet that refuse to acknowledge it's an issue, and will flame anyone who brings it up. As a result, when new users try out Emacs and see that the performance sucks, many of them will instantly uninstall and return to VS code, and the userbase suffers. [0] https://www.reddit.com/r/emacs/comments/ymrkyn/async_nonblocking_jsonrpc_or_lsp_performance/ https://www.reddit.com/r/emacs/comments/ymrkyn/async_nonbloc...

G3rn0ti 3y ago
> instantaneous fuzzy autocompletion on every keystroke- the GUI would lock up every time autocompletion is engaged, I am using lsp-mode enhanced autocompletion (using company.el) and I have never observed such a problem. I set the autcompletion delay to 0.0 in my case and work on 1k LOC modules. If you enjoy VS code, I am glad for you. It is certainly a good editor. But don't post generalized slurs against Emacs if you obviously haven't used it for long. Performance issues can happen but that highly depends on the context. What combination of language server, language server client and what language is causing this? Edit: If you are new to "lsp-mode" and you have performance issues, take a look here: https://emacs-lsp.github.io/lsp-mode/page/performance/#json-native-serializationdeserialization https://emacs-lsp.github.io/lsp-mode/page/performance/#json-... Also consider trying other LSP servers if available. For popular languages there are usually several alternatives to choose from: https://langserver.org/ https://langserver.org/
- BaculumMeumEst 3y ago
  I mentioned that bringing up performance issues will bring you insults and dismissal, and you saw fit to reply with: > I have never observed such a problem > don't post generalized slurs against Emacs > If you enjoy VS code, I am glad for you. > you obviously haven't used it for long I guess it did not occur to you that you are immediately proving my point. To answer your question, the context is literally every single language server. Not only with autocompletion delay to 0.0, but also setting the minimum prefix to 1, so that it activates on every keystroke; the default is 3. The fuzzy completion cannot be configured out of the box, of course, it requires another extension. I posted a thread with much detail on why it occurs. You can downplay all you'd like, but a non-issue does not spur a productive maintainer to fork the entire codebase to implement changes, or alternative clients (LSP-bridge) that manage out-of-process connections to servers in order to work around Elisp limitations.
  - G3rn0ti 3y ago
    Well, Emacs has indeed a problem with blocking because it is single-threaded. To resolve that issue internally it also maintains an event loop being used to drive async. functions calls. But not all extensions leverage that yet. But I doubt the problem described in that reddit thread you cited is really caused by that. It sounds more likely the author of that Emacs fork experienced an issue with inter process communication. Who knows because there is no detailed context given. I am using "lsp-mode" for Javascript, Typescript (including React) and even on a huge Perl repository and I don't find it to be too slow for me. I am running a five year old mediocre laptop using Ubuntu. But perhaps I don't have the same standards as the author of that Emacs fork. > You can downplay all you'd like, but a non-issue does not spur a productive maintainer to fork the entire codebase to implement changes, or alternative clients (LSP-bridge) that manage out-of-process connections to servers in order to work around Elisp limitations. Well, it's an impressive feat, for sure. But I don't know anyone actually using that person's fork. So I wonder whether that really is such a huge problem as the author implies. And -- why do you care anyway since you seem to be happy using VSCode?
    - antoineMoPa 3y ago
grgbrn 3y ago
> VS Code in its current state has no perceptible input latency on modern hardware, easily verifiable. "easily verifiable"?!!? This is a ridiculous statement - lots of VSCode responsiveness is dependent on which language servers you're using, and some are definitely faster than others. Sounds like you're extrapolating from the languages that you personally use? The golang LSP has had widely documented performance problems on large codebases on and off over the past 2ish years (mostly resolved at the moment AFAIK), but it was severe enough that a large percentage of my group at work switched to Goland (Go IDE from Jetbrains) because it was much, much less laggy on our larger projects than VSCode.
antoineMoPa 3y ago
Not sure why you are getting downvoted, I think this is exactly the issue I'm seeing.
- grgbrn 3y ago
  I didn't downvote this post, but I don't find it hard to see why someone would: * making incredibly general hand-wavy statements implying vscode is always perfectly lag-free and emacs is terrible * generally condescending and hostile tone: "if you invested the time.." "you saw fit to reply with" * some ranting and name-calling about a previous negative experience this person has had, which has nothing to do with anyone in this thread. (given the general tone of this post, i'd say there's a good chance that it was just this person deciding to abuse some unpaid emacs/lsp volunteer/maintainer and they rightfully said "go fuck yourself") * sadly, there is actually useful information contained in this post, but it's sort of structured as an inverse "shit sandwich" - some ranting and negativity, some useful and relevant information, and then more ranting and name-calling. which, i think, tends to mean most people are just going to ignore it or downvote. not really a constructive contribution to the discussion, despite actually having something useful to say
  - antoineMoPa 3y ago
    Yeah, makes sense. Parts of it resonated with me, but it's also a bit too rude.