Feature Request: Zero-latency Typing

[aniljava]

Following articles goes into length describing the issue in general.

• https://pavelfatin.com/typing-with-pleasure/
• https://blog.jetbrains.com/idea/2015/08/experimental-zero-latency-typing-in-intellij-idea-15-eap/
• https://news.ycombinator.com/item?id=10787812

The subtle typing lag is observed in VS Code in same machine in which the typing is lag free with sublime text and even eclipse. This feature request is to look into the issue and address it if feasible.

[Chillee]

I performed the tests listed at "Typing with pleasure" on my own computer, and these are my results:

[mauro3]

I just ran some typometer tests as well, here the results (note the SD column is the standard deviation):

Here some interesting plots, comparing VSCode behavior of synchronous setup (a new key is only pressed once the last is displayed):

and asynchronous

Also note that some extensions can increase typing latency considerably: https://github.com/SebastianZaha/vscode-emacs-friendly/issues/20

Edit: this is on a Linux system with xmonad window manager.

Edit edit: If you get typometer timing out with "cannot detect char" at some point. Then, to fix, zoom in a lot. Also, you need at least one other line which is wider than the screen to make it work. Also, it's recommended to use a non-block cursor but I didn't see any difference there.

[codecat]

Yesterday I tried switching from Sublime to VSCode, but sadly am returning to Sublime again today because of this issue. Would love to see this fixed in VSCode.

[amritk]

@codecat I was in the same boat as you, but VScode has so much else going for it I switched back again from sublime even with the lag.

[SebastianZaha]

In the case of the emacs extension, the old one had some code that was registering the "type" command to implement some more complex keybinding systems.

I have removed it and I think the latency overhead is fixed. (in v0.8.0 of https://marketplace.visualstudio.com/items?itemName=lfs.vscode-emacs-friendly)

The typing latency is quite spiky though, even with no extensions, at least when trying to graph it with the aforementioned program.

[codecat]

Yes, I notice the input lag without any extensions installed.

[ziriax]

Not only am I experiencing input lag, but lately I also have to press the cut/copy/paste keys rather long, otherwise nothing is copied to the clipboard. Not sure if this is related, but it is extremely annoying. Although of course every good programmer never copy/pastes ;-)

[richardgirges]

Not only am I experiencing input lag, but lately I also have to press the cut/copy/paste keys rather long, otherwise nothing is copied to the clipboard. Not sure if this is related, but it is extremely annoying. Although of course every good programmer never copy/pastes ;-)

I'm experiencing this exact same issue. For instance, I have to explicitly hold down the command key on my mac, and then press C afterwards in order to copy. If I do it too fast, nothing gets copied. In some cases, the C key is registered before the command key and the VSCode will end up typing the letter C into the editor. I don't see this behavior anywhere else other than VSCode :(

[chmln]

For someone with >100 wpm, the input latency is unbearable and no amount of features can compensate for this. It is a text editor after all.

If the behemoth of IntelliJ IDEA could do zero latency, so can VSCode. Its great to see work done on the performance front, and hope this is just the beginning. :+1:

[pcgeek86]

I'm experiencing typing lag on a Dell XPS 9350 running Windows 10 1709 (Fall Creators Update). It doesn't seem apparent in other applications, like Firefox and Chrome, but is quite noticeable in Visual Studio Code. I've noticed the typing lag while editing a JavaScript file in particular.

[pcgeek86]

The problem is especially noticeable when your Windows 10 power settings are configured to improve battery life. I'd recommend any testing be done with similar power settings, and reduced CPU performance.

[syifan]

Same thing here with @pcgeek86. I can accept the latency when my laptop is connected to power. But I cannot accept the latency when my laptop is on battery.

[akellermann97]

I love this idea. Really low latency is such a pleasure to use.

[syifan]

Finally got a chance to benchmark vscode on my machine using typometer. Here is the latency distribution when my laptop is on power. I am using a Dell XPS 9360 laptop running ubuntu 18.04. From my experience, I have similar latency in windows. I cannot get typometer working when using battery. Probably it is because the latency is too high. I can feel that on battery has probably 2-4 times longer latency. The related extensions are vscodevim and vscode-go.

Here is the result when I use vscode on battery

To make sure there is no problem with my hardware and os, I also benchmarked GVim and here is the result.

I cannot believe why the latency is so high. My latency is very different from what mentioned in the previous posts. How can I debug where the latency comes from? I tried to use the developer tools, but I cannot figure out too much from the profiling timeline.

[flagbug]

Same issue as @pcgeek86 has. When plugging in my laptop, there is no noticable latency, but as soon as I go on battery, it's unbearable. This is especially noticable when pressing and holding the backspace key, I regularly overshoot the text that I actually wanted to delete.

[rupinder02]

I had the same issue. There was too much of latency while typing. Disabling the in built extensions worked for me.

[sethlivingston]

Disabling some rarely used extensions and turning CPU performance up to 11 significantly improved my latency, but I would still love to see zero latency.

[SamLeatherdale]

Sorry for the necro, but I did notice that starting VS Code with the command line flag --disable-gpu increased the response time significantly.

[Tactleneck]

Is there something that could be done to lower input latency? I can find some time somehow to help with this amazing project but I don't know where to start. Could the incoming move to electron 3.x help somehow with latency? Because it looks really close to release and it could be better to wait until then. Thank you to all the developers and community.

[wdhwg001]

Actually this latency is the most significant thing that makes VSCode not that "native".

And I don't think it should be heavily related to extensions. It could be hard to benchmark the latency caused by a extension. And it is actually suggesting users to install less extensions to make VSCode faster, which is against the purpose of the extension system.

Any progress on this feature?

[sethlivingston]

This is one of those features that transcends the number of votes its getting. Getting to zero latency or at least much closer would benefit every single user. Please add to the roadmap. Thank you, developers.

[jacktuck]

Unfortunately the only fix would be to get rid of electron (become a native app) and at this point it's probably too late?

[max-sixty]

Does anyone have any actual data on the latency on a recent version?

Even with the headline number (no attribution where it's coming from), this would give some power to the thread

[sethlivingston]

@jacktuck Are you certain that's the problem?

@max-sixty got a camera? :) http://renderingpipeline.com/2013/09/measuring-input-latency/

[pylang]

I updated to 1.29, experienced input lag and then reverted to 1.21.1. Sadly, most of my extensions stopped working immediately after this upgrade process. If possible, it'd be great to know about regressions, prior to uninstalling a version that does work to install one that does not.

An alternative could be a Revert option to allow ppl to try the new features and test regressions prior to uninstalling the previous version fully.

[iamtheoneaboveall]

As someone who has a 165Hz display its very noticable even pressing a single key in VS Code, it feels too delayed and heavy, to the point that it makes every keystroke feel as if i'm lifting 50g with a finger.

[wdhwg001]

Any progress?

[wdhwg001]

I honestly don't understand why a code editor choose to ignore its typing experience. Any updates?

[str4]

This makes vscode unbearable for me. Even with the --disable-gpu -option the input lag is too much for me. I like what vscode brings to the table compared to sublime, but as for now, I'm sticking with sublime.

[Nathan-Franck]

Yeah it's an issue that makes me uncomfortable using vscode for extended periods of time, especially when my computer is compiling or doing anything processor intensive ---

An easy latency test is to try highlighting a bunch of lines of code in VSCode and see the highlight visibly lag behind your cursor. Sublime Text and Microsoft Visual Studio do not show any latency between cursor and highlight.

[proprietary]

Not possible because of V8's memory model. I am used to setting a rapid key repeat rate on my keyboards with xset(1), causing VS Code to hang up to 10 seconds especially with some of the heavier linters + Vim emulator extension (worst offender). The only editor I've ever used that has never choked was stock vim.

[reinux]

causing VS Code to hang up to 10 seconds especially with some of the heavier linters + Vim emulator extension (worst offender).

I switched to asvetliakov.vscode-neovim. No more brutal latency.

[osor-io]

Has there been any more improvements on this? On Windows 10 with the forced compositor on and running in a single 120hz screen I get around 8 ms of average lag in lightweight editors like gvim or 4coder. And I get around 17/18ms on vscode.

I'm loving some of the functionality and the plug-in richness but the fact that just editing text is that much more sluggish than other options is a big downside.

[thany]

Latency happens with more than just typing. I've noticed a real visible lag when selecting text by mouse. Another really visible (and to me nausciating) lag is when I scroll using a two-finger gesture. Oddly enough scrolling by clicky mousewheel feels completely instant (smooth scroll is disabled).

Typing lag on my computer feels a lot more than 25ms though. What's more, when I hold down a key, the editor can't keep up with the rate at which keypress events are produced. So it's not only laggy in this case, but jerky as well.

I'm on a XPS15 with Core i9-8950HK with 32GB RAM, working on Intel UHD 630 graphics. This laptop also has a GTX 1050Ti, driver is at 441.45, but I don't think it uses this GPU for desktop workloads. I'm at "best performance" profile, and plugged into the mains.

[fathom-matthew]

Can the work done integrating a WebGL renderer ( https://github.com/microsoft/vscode/pull/84440 ) apply here?

[alectrocute]

I want so desperately to make Code my full-time, cozy editor; The subtle input lag is unbearable. I get ~35ms of input lag on a spec'd ThinkPad X1e. 😢

[ngrilly]

@alectrocute How do you measure that 35 ms input lag?

[pedrib]

@ngrilly https://pavelfatin.com/typometer/

[runningdavid]

happens on my windows 10 machine as well, after installing the Win 10 Edge update

[johnathanz]

same issue here on a a spec'ed out 2018 Macbook Pro. Given typing is such a fundamental aspect of a Text editor, would be great to see this issue addressed.

Happy to help with testing etc. For now switched back to Sublime Text.

[str4]

My results using the aforementioned speed tester with 2018 macbook pro (empty file)

Vscode: 26ms Sublime: 22.4ms Webstorm: 25.6ms Vim(with alacritty as a terminal and tmux): 16ms

However, when editing a file with code in it, vscode jumps to 50-60ms. Of course linters are going to affect this, but using the same type of linters in vim, it only jumps to 25ms from 16ms.

[thany]

That feels like "background process" (for linting and whatnot) in VScode only, means "while idle", while in other editors it means "on a separate thread". It's an assumption, but it would very much explain the difference you get when a file has code in it as compared to an empty file.

We all have 4+ cores in our computers. Let's put them to use 💪

[matthiasg]

Is there any discussion around any actual implementation ideas ? I am not in to the actual typing rendering pipeline and speed. I would assume, provided single line editing is already optimized, that directly drawing letters on a canvas (at least during the typing) would be the lower limit. There would be added overhead for text flow etc.

The question is, what is the current lowest limit in an HTML rendering scenario ? If that is not low enough for the majority of people interested in this feature the HTML rendering pipeline in the browser would need to be improved first or some kind of text pipeline added.

[MaffooBristol]

This lag combined with the Macbook butterfly keys issues is making my job very, very frustrating. And I'm on a maxed out laptop...

[joshk0]

Does the new Local Echo behavior help with this any?

[MaffooBristol]

Does the new Local Echo behavior help with this any?

I don't think that really applies, as it's only in the context of the integrated terminal, and mostly only an issue when running over SSH

[dmohs]

@matthiasg

The question is, what is the current lowest limit in an HTML rendering scenario ?

I think that is an excellent question. Using the "Is It Snappy?" iOS app, I tested this on a 2019 Macbook Pro. This means I'm using my eyes to judge based on slow-motion capture, but I got 50ms for a plain textarea element in Safari. For comparison, I also got 50ms for Sublime Text.

[basaran]

This is still a problem with vscode, the latency is not noticeable when you are typing a few words, but when you start working on a project, every key feels like there is a chain attached to your fingers. Sublime is better with latency, with less deviations and somehow jetbrains is the fastest around 10-15ms. You really do notice it when you are working. Unfortunately, Jetbrains is not perfect either, they have terrible font rendering if you are on a low dpi display.

To sum it up, this is my experience based on ergonomics:

VsCode: features: great font rendering: okay lag: not okay

Sublime features: not okay font rendering: great lag: bearable

Jetbrains features: okay font rendering: not okay lag: great

There are probably other factors which ruin the typing experience on all platforms, including but not limited to usb interface, screen refresh rate, screen latency, keyboard latency, gpu drivers. Sadly, since 3d became mainstream, it seems nobody really cares about the 2d performance anymore.

[basaran]

For a baseline comparison, this is the typometer results from plain cmd on a windows 10.

As you can see, most of the keys are registered around 6ms, and just compare this to any text editor, you will find yourself in a lot of joy while you are typing random words.

this is VI inside cmd

new windows terminal app

alacritty

My next goal would be to side boot FreeBSD on the development machine and run the same tests there. FreeBSD might have lower latency compared to Windows, and Linux. If anybody had done it already, please share your results.

[CSaratakij]

2021, and this still open..