10 ms·
Typometer: A tool to measure and analyze the visual latency of text editors
- userbinator 6y agoThe companion article at https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/ has some example results, showing Atom, the only Electron-based one in the list, as having several times more latency than the others. I wonder how VSCode compares. It's unfortunate that software seems to feel slower the newer it is, including developer tools such as text editors/IDEs. I suspect this is because most people - including younger developers - have never seen how fast things can be, but are instead constantly subjected to delays in using applications to the extent that they think it is an absolutely normal speed[1], and then propagate that notion to the software they themselves create. Also related: https://danluu.com/input-lag/ https://danluu.com/input-lag/ [1] For example, everything that uses UWP in Windows. Someone who had only ever used the Settings app in Windows 10, or (even worse) the Calculator, might not realise how absurdly slow they are in comparison to the previous versions' where they would open nearly instantaneously.
- lucb1e 6y agoDirect link to the section with Windows results: https://pavelfatin.com/typing-with-pleasure/#windows https://pavelfatin.com/typing-with-pleasure/#windows Scroll a bit down for Windows with power saving, Linux (section 3.4), and VirtualBox (3.5).
- jhurliman 6y agoThe worst is when I see someone using vim or Emacs over SSH. If you think Electron apps are bad, imagine adding a network round trip between every keystroke!
- vz8 6y agoGui Emacs via tramp+ssh is awesome. Terminal Emacs over ssh is, well, just like anything else in a terminal over ssh. Can't say I notice the latency unless the datacenter is on the other side of the country.
- cyberbanjo 6y agoIsnt it the same if you use tramp in the terminal, assuming you are running emacs locally and tramping into the server to edit?
- sgillen 6y agoSure, although in that case why not use the GUI?
- ben0x539 6y agoidk, vim across ssh (rn from my place in the west coast to a vps in iirc the east coast) feels a lot snappier and less frustrating than my typical interaction with slack.
- beering 6y agoSuggestion for anyone who's annoyed by SSH latency - try out mosh[0]. It watches to see if your keystrokes are echoed and if they are, it'll start echoing your keystrokes locally without waiting for network roundtrip. That, plus the ability to rejoin a session even from a different IP, makes working over SSH doable even from airplane Wi-Fi. [0] https://mosh.org/ https://mosh.org/
- sumedh 6y agoYou can use programs like winscp to open the file locally in your fav text editor and then upload back to the server when you click save.
- tkzed49 6y agoI actually don't think that developers who use things like VSCode are simply naive. Personally, I am a young person and I frequently do use vim in a low-latency terminal emulator (xterm, mlterm) without a compositor. Yes, I enjoy the fact that it is very fast. However, I still use VSCode when I'm making more complicated edits primarily because of the plugin ecosystem. Plugins "just work", are easy to configure, and all work together nicely. I get rich syntax highlighting and intellisense. I might be doing something wrong, but this was not the experience I have had with vim. I like the UI simplicity of VSCode in contrast to native editors such as IntelliJ and Visual Studio, which I do use when I really need the features. I am interested in efforts like Onivim 2, which seek to combine these advantages.
- Shared404 6y agoVim + Alacritty + Gruvbox = Happiness. For me at least. I've found that I get perfectly passable syntax highlighting with vim, and haven't needed anything else on my current install. If I did use an editor other than vim, I would probably use VSCodium because open build, and I do really like the visual style.
- denosawr 6y agoYou might be interested in coc.nvim, which can allow vim to use the LSP servers which powers VSC's intellisense. It's a bit of setup, but I've found with coc.nvim and a good syntax highlighting plugin, I can get a really great syntax highlighting and intellisense setup going.
- twoleftfeets 6y agoAgreed. I've been editing since the late 70s. At the moment I use VSCode the most. The plugins are the thing. They are doing things I've seen no other editor do. Of course I haven't used every editor. The latest was I typed ...nameOfArrayInOtherFile and it auto inserted import nameOfArrayInOtherFile from './tests/name-of-array-in-other-file.js'; a few lines above some how recognizing the pattern. Another thing I've seen VSCode do is give me library specific warnings. Maybe that's common now-a-days in other editors but I hadn't seen it before. I'd seen language warnings but not library warnings.
- noble_pleb 6y agoPlus the new generation is pampered with much cheaper resources (RAM and CPU), so programming efficiency goes out of the window.
- deleted 6y ago[deleted]
- contravariant 6y agoI also can't be the only one annoyed by the input lag in the windows login screen and start menu search. Somehow both of them seem to think it's fine to just ignore keypresses for half a second before doing anything. Annoyance aside I seriously worry about the accessibility of the windows lock screen. Through a weird display setup I sometimes find myself trying to log in blind and I just can't do it. There seems to be no way to reliably focus the password field, and for whatever insane reason it's not just always in focus
- mwcampbell 6y ago> Annoyance aside I seriously worry about the accessibility of the windows lock screen. Through a weird display setup I sometimes find myself trying to log in blind and I just can't do it. If you try running a screen reader, such as Narrator (built into Windows; edit: turn it on and off with Ctrl+Win+Enter, even on the logon screen), you should find that even if the focus somehow gets away from the Password field, you can get back there with the help of speech output. Logging in blind doesn't have to mean logging in with no means of orientation. (Disclosure: I'm a developer at Microsoft on the Windows accessibility team, working on Narrator among other things.)
- contravariant 6y agoFair enough, but on a screen who's sole purpose is to let me type in my password I really shouldn't require a Narrator to find the one and only input field. It's nice that the problem has a solution, but it shouldn't have been a problem to begin with.
- mwcampbell 6y agoThe trouble is that this screen isn't just for entering your password. On my logon screen, I have not only the PIN field (because I enabled the TPM-based Windows Hello feature), but also these other links or buttons: "I forgot my PIN", "Sign-in options", network, Ease of Access, and power. So use of a full GUI framework, that supports accessibility tools such as a screen reader, is justified.
- senkora 6y agoA few months ago I found my old GameBoy and played through part of "Kirby: Nightmare in Dreamland". I know its not the most well-known game, so the relevant detail is that it relies a lot on timing and quick movements. I was completely blown away by the responsiveness of the controls. The control feedback was instant, frames were rock-solid, and there were no loading screens at all. When I put down the game, I was just tremendously sad. I'd forgotten what instant feedback felt like.
- dahfizz 6y agoIt really amazing playing with old technology. In Super Mario Bros on the NES, when you press the jump button Mario jumps the very next frame. And with a CRT you get instant response time. You just can't get that responsiveness anymore.
- yjftsjthsd-h 6y agoWait, why would a CRT be faster than LCD? If anything, I'd naively expect faster response with no electron beam to move.
- ce4 6y agoThe NES-CRT connection is analog and the screen is drawn line by line, if you connect a digital monitor that will have to be buffered and you get some delay/lag of min 1 frame.
- mrob 6y agoMost LCDs only buffer a single line at a time: https://www.youtube.com/watch?v=wts8f1bNnbo https://www.youtube.com/watch?v=wts8f1bNnbo
- formerly_proven 6y agoYou misunderstand the video. A LCD controller must buffer at least one line, because the LCD matrix is updated line for line, all columns in parallel -- it's a matrix, much like a RAM matrix. However, the video just shows how the LCD is scanned out, it doesn't say anything about the buffering of the controller. A lot of non-gaming LCDs, and virtually all older non-gaming LCDs, buffer an entire frame, even if they are driven in their native mode.
- dsissitka 6y ago> I wonder how VSCode compares. I was curious so I did some tests: https://imgur.com/a/73coWRR https://imgur.com/a/73coWRR
- comfymatrix 6y agoThanks for this. I definitely wasn’t expecting VSCode to be almost on par with Emacs...
- agumonkey 6y agoI tried vscode on win10 core i5 1st gen. Could barely reach 2 keys per second. I was honestly shocked.
- hrktb 6y agoIsn’t it because older tools never go away ? Newer tools only come as alternatives to faster tools that continue to be usable at any time. For instance I choose to use VSCode and consciously weight it down with plugins and extra linters, because the trade-off is fine for me. But I know vim is only a click away, and if I wanted sheer speed I’d do it there. And I actually do use it on a day to day basis, it’s just not my primary editor.
- fxtentacle 6y agoI would say the big outlier here are the JetBrains IDEs like IntelliJ, which have had zero-latency as their default configuration for 2 years now. Also, it is worth noting, that the same person doing this research is the one working for JetBrains on optimizing editor latency: https://blog.jetbrains.com/clion/2017/01/clion-starts-2017-1-eap/#zero_latency https://blog.jetbrains.com/clion/2017/01/clion-starts-2017-1... So there are companies taking the editor latency issue seriously and that are close to fixing it.
- formerly_proven 6y ago> Because sampling rate is fast enough to misinterpret contact bounce as keystrokes, keyboard control processor perform so-called debouncing of the signals by aggregating them across time to produce reliable output. Such a filtering introduces additional delay, which varies depending on microcontroller firmware. As manufacturers generally don’t disclose their firmware internals, let’s consider typical debouncing algorithms and assume that filtering adds ~7 ms delay, so that maximum total “debounce time” is about 12 ms, and average total debounce time is ~8.5 ms. Debouncing in software is one of those things that 99 % of developers get wrong, and is something even hardware manufacturers get wrong all the time. A lot of hardware debounces in a dumb and naive way: On the first state change, it waits 5-10 ms and sample the switch again to figure out if it was pressed or not. So you get an inherent "debounce" delay, which is entirely unnecessary. Debouncing keys correctly works so: If the switch generates an edge, sent key down/up event immediately and ignore further switch transitions for 5-10 ms. There is no point in waiting for the switch to surely have finished bouncing before reporting the event, because if it is bouncing it MUST have been pressed/released and you know which one it is because you know the prior state of the switch. --- Compositor delay due to VSync Obviously compositors are using double-buffered vsync precisely because they intend to limit FPS to $smallValue in order to save power and prevent the 3D hardware from entering a high performance power state. They really should be using triple-buffered vsync, but only start to render if something changed, resulting in much lower latency without constantly running at 1000 FPS. There should be a way for the compositor to be notified of changes in client areas, since stuff like X11 damage protocol and RDP are a thing.
- kevingadd 6y agoUnder normal circumstances Windows' DWM compositor will avoid compositing at the display rate if nothing has changed. It used to be pretty easy to demonstrate this by using a hook application (like fraps) to put a framerate overlay on DWM, though I don't think that works anymore. If you have g-sync enabled for the active windowed application, the DWM composition rate (and the monitor scanout as a whole) will be tied to the windowed application's vsync, so if it's running at 30hz so is your desktop until you tab away. Many G-Sync monitors have a built in framerate overlay you can toggle on to observe this (though the lag on your mouse cursor will make it obvious). I suspect in practice most software is not very good at giving the compositor the info it needs to avoid wasteful refreshes of the whole desktop, and the compositor probably also isn't putting in as much effort as it could.
- PragmaticPulp 6y agoI'm all for faster software, but input lag measurements need to be put in perspective. Just because an editor can process an input in 3ms doesn't mean the pixels will change on your screen in 3ms. If you're using a 60Hz monitor, you're only going to see new frames every 17ms at most (1 second / 60Hz). Your graphics pipeline might have some additional buffering, adding 10s of milliseconds of lag. Your monitor likely has some input processing as well, adding anywhere from 10-20ms before it sends the frame to the physical display. Add a few milliseconds here and there for input processing and even the response time of the physical pixels, and you're looking at something like 50-60ms minimum for total display latency before you factor in the software. Using 144Hz FreeSync or G-Sync monitors can shorten that update time, but you're still looking at 30ms end-to-end latency in even the fastest setups, and that's before you account for software processing lag. The difference between Sublime Text responding in 11.4ms average and Atom responding in 28.4ms average is difference of almost exactly 1 frame of latency for a typical 60Hz monitor. Add up all of the other sources of lag (buffering, monitor input lag) and you're looking at something like a 5 frame latency instead of a 4 frame latency. Still less than the blink of an eye (literally). From another perspective: If you really believe that you're sensitive enough to feel a difference between something like Sublime Text's 11ms processing latency vs. Atom's 28ms latency, then you might want to invest in a proper 144Hz gaming monitor with low input lag, as it would improve your experience by the same margins. A gaming-specific keyboard might also help, as average keyboards can have 10-20ms of input lag before the keypress registers with the OS (Source: https://pavelfatin.com/typing-with-pleasure/ https://pavelfatin.com/typing-with-pleasure/ ) Realistically, though, I doubt many people could A/B test the difference between a 1ms and a 30ms latency editor under ideal conditions, let alone while typing out some code.
- RcouF1uZ4gsC 6y ago>The difference between Sublime Text responding in 11.4ms average and Atom responding in 28.4ms average is difference of almost exactly 1 frame of latency for a typical 60Hz monitor That is looking at the average latency for Atom. If you look at the max latency Atom, it is 60ms compared to 15 ms for Sublime text. That is basically 3 frames of latency difference on a 60Hz monitor, and would definitely be notable for the average person.
- arexxbifs 6y agoSeeing as how this and similar articles regularly crop up here, I'm curious as to when this started and why nothing is done about it. I still regularly use my 14 MHz Amiga 1200 for recreational programming and I _never_ experience input lag on that machine. Thinking back, the first time I noticed input lag was on a Mac LCIII running Word in the mid-90s. Then for a long long time I didn't come across any particularly noticeable latency, except on really crappy websites and in really crappy Java apps. Then Microsoft bought Skype and started working their magic on it, and this seemed to open some kind of floodgate of high-latency crap. That's not even a decade ago. After that, little by little, everything seemed to slow down noticeably. We've now reached a level when this is seemingly normal. Even programmer colleagues who are my age and older are looking at me like I'm curious when I complain about the latency. I'd say something toxic about Electron here, but it's prevalent in native programs as well. Have things really gotten so much more complex since 2010 that we can no longer put a character on screen in a timely fashion?
- jiggawatts 6y agoThere are underlying reasons, much of which can be gathered under the umbrella term of "virtualisation". Modern computers use layers upon layers of software or hardware to present an interface pretending to each higher level that things are simpler than they really are. These abstractions, however, are leaky, and almost all of them are leaky in the temporal sense. There's a pretend continuity or constant throughput that's not really there. Everyone knows that operating systems run short time slices of processes on physical cores, so that each program can "pretend" that it runs continuously on bare metal. But of course, not really, so there are gaps in the flow of execution that can occasionally be perceived by end-users. If that were the only sin of pretense, then that could be worked around, or carefully tuned, but the reality is that it's just one of many layers. The garbage collector of managed languages (e.g.: JavaScript in Electron) pauses execution within the process too. Even unmanaged languages have variable overheads when allocating or de-allocating from the shared heap. The desktop window manager helps each application pretend that it has a rectangular surface from (0,0) to (w,h), when in reality that is transformed and overlaid. That can introduce a lot of variation, particularly because the DWM has its own threads and its own garbage or heap. The video card in turn is no longer just a block of memory mapped into the address space of the program doing the drawing, but is its own little computer with cores, threads, schedulers, locks, clocks, delays, and so forth. The display in turn might further delay things because it has complex overdrive or scaling logic, so it needs to buffer frames. It's turtles all the way down.
- 29athrowaway 6y agoUsing Java to measure latency... Does not sound very accurate.
- drewnoakes 6y agoWhy not?
- 29athrowaway 6y agoBecause in a garbage collected language, most of the time you have little to no control over how and when the garbage collection takes place, and how long it will take. That's the reason you won't see a Java-based pacemaker anytime soon.
- coronadisaster 6y agoeither way, if your text editor editor lags, there must be a bigger problem... or are we back in the 60s?
- fxtentacle 6y agoIt's called Electron and it shouldn't have been used for building desktop apps in the first place. I presume it was built as an inside joke when people were joking about web browsers becoming the new OS. That said, it allows companies to use cheap web developers to build (previously more pricey) desktop apps, so it's used everywhere now. It's good enough to make money, but obviously using the wrong tool for the job will make some aspects of the experience worse. Since most consumers hate working with the buggy software on their computer anyway, the loss for a company in making it slightly worse by introducing delay is negligible.
- 29athrowaway 6y agoWhen you compare Winamp 2.x with Spotify, you realize how slow software is today.
- vardump 6y agoCorrect me if I'm wrong, but this doesn't seem to measure input stack latency nor how long it takes for the pixels to be actually visible on the display after all of the compositing delays. All this measures seems to be time from injected keyboard event until pixels change on whatever bitmap/surface in memory. Message passing, in other words.
- wtallis 6y agoThat sounds like it's measuring almost exactly the portion of the end-to-end latency that an application can actually do anything to reduce; the rest is in hardware and drivers. So it would definitely be a useful measure, but cutting this measured latency in half won't cut the entire end-to-end latency in half.
- vardump 6y agoApplication might be able to make choices about APIs that affect output latency. Hardware swap chain (AKA multi-plane overlay) is going to be visible on the screen at least one full vsync faster than something that's composited on a frame buffer. In the best case, this measuring method wouldn't see any difference in such case. In the worst case reading pixels from the screen might even misleadingly measure worse due to triggering a corner case code path in the window compositor. Using an emulated legacy API (like Windows GDI) might yield a very low latency score in this test, even though it might take much longer to actually be visible on the display.
- galaxyLogic 6y agoI've been working on a browser-based editor, and it feels slow. So does this input-field on Hacker News website. Is it something about the browsers?
- fxtentacle 6y agoI would love to see XCode on that benchmark, as I regularly manage to out-type it.