Typing with pleasure
pavelfatin.comGreat to see this quantified! My pet peeve is laggy interfaces. I'm not surprised to see Atom on there, because browsers do seem to have a big problem with this. Ubuntu seems to have a big problem with this too, e.g. in the native "gedit".
Back in the Ubuntu 4.0 days (2006 or so), the default terminal was really slow. I didn't really know how to use Linux then, so I would SSH into with Putty on Windows, and use the terminal/Vim that way. This was actually more responsive than a local terminal!
Does anyne else feel a sense of raw power when they switch to a native terminal (Ctrl-Alt-F1) ... ?
Try out mosh. Local buffers really make a difference for that latency.
Well I was saying that using a shell or vim via Putty/SSH from Windows (and a fast corporate network connection) was actually MORE responsive than sitting at that computer, and using GNOME terminal or whatever it was!
I've heard of mosh though -- it sounds cool.
This is a terrific writeup about the latencies of text editors. Now the next step is to research the effects of latency on cognitive strain, typing accuracy, and typing speed.
Without that, the latency numbers themselves don't mean much. Some 100 ms latencies are readily noticeable (video game input), others are not (pushbutton responses).
This paper (http://www.tandfonline.com/doi/abs/10.1080/00140137608931531) seems to suggest that typing speed does decrease at higher delays, but recovers after a short time. I can't access this journal though, so I don't know what kinds of delays were tried, and I don't know how long the recovery time actually is.
And here I am, working over SSH -- every stroke requires a round-trip. Over a high-latency link, that's sometimes a few seconds between a batch of characters appear :-)
Give Mosh [1] a shot! From the site: "Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes."
Great for being on an intermittent and/or slow link.
"and provides intelligent local echo and line editing of user keystrokes."
I've always pushed for this to be in the remote terminals by default as my prototypes took almost no effort to implement. With plenty of benefit, too, for anyone that values instant feedback! That was a throwaway, though. Thanks for the link to a real app doing it. :)
Emacs TRAMP is excellent for editing files over SSH. Even if you have to have a separate terminal for doing things like restarting services, doing the editing locally and updating via TRAMP is a big win.
I found that in such cases it's actually more productive to close my eyes while typing.
I really enjoyed that write up. The only piece I would love to see added would be the addition of emacs and vim in a native console.
Yep, I once had just a native console open when installing linux freshly and the lag was so low that I immediately felt how much better it was and that it made me think about lag.
I use terminal based Vim exclusively and now I'm completely spoiled. Every other interface seems ridiculously "laggy". I don't know if it's just a psychological thing or something more like the SpeechJammer, but if I type at a co-workers computer I will sometimes completely lock up and be unable to type for a second or two.
I really don't think that is a psychological thing, i ben using emacs in the terminal for years and only within Apples default Terminal application because iTerm is really laggy on linux i prefer terminology that is really really fast
+1 for terminology. Fast even on the cubieboard that I (also) run it under, and somehow, in my opinion, it does font spacing really well even under Ubuntu. Better than the standard terminal in both Unity and (especially) Gnome where kerning can be weird even on mono font.
No framebuffer, right? In my experience, the framebuffer introduces an annoying and noticeable delay.
I just did quick measurements for vim 7.4 and emacs 23.4.1 in xterm, rxvt/urxvt, and gnome-terminal. The results depend most strongly on the terminal type. emacs' latency is always a bit (0.1-0.3ms or so) lower than vim's. Apart from that, xterm was around 1.1ms, (u)rxvt around 17.5ms, and gnome-terminal around 26.2ms. I wonder where the delay in rxvt compared to xterm comes from.
Depending how you're measuring it, I believe it could be because urxvt's output is buffered by default whereas xterm's isn't. That may mean 16.7ms (= 1 second / 60Hz) is added to the measured latency, though the extra time would have no effect in practice.
ed: or maybe thats excluded from the measurement but urxvt is double buffered by default?
You're right, urxvt refreshes at a maximum of 60Hz (line 1021 in http://cvs.schmorp.de/rxvt-unicode/src/command.C?view=markup). Above, I mistakenly measured only urxvt. Rxvt does a select() with a timeout of 5ms before redrawing (lines 1600 and 1664 in "src/command.c"). The total latency with rxvt is about 5.7ms.
One of the bigger problems with emacs is its font highlighting mechanism - typically it's implemented with regular expressions adding stacked attributes to text. Lexical highlighting using a state machine, with state recorded at line start would be much much faster - like, multiple 1000x faster. Emacs pays for its flexibility with massive performance loss.
Compare something like joe editor (the jmacs named executable has emacs-like key bindings) for syntax highlighting; it's night and day. Joe uses state machines (DFA) in a text description format for syntax highlighting. That means that strictly it can only do lexical highlighting, but that's much much better than nothing - and fully correct syntax highlighting requires a deeper analysis than is normally done in emacs modes.
Joe itself would be much faster again if the state machine was compiled to machine code.
Terrific data (okay, so it confirms a preexisting bias on my part). I would like to see the numbers for Visual Studio -- I've completely sworn it off at my day job in favor of Sublime Text + command-line MSBuild, for typing latency alone. I'm curious if my perception aligns with reality.
The improvement with intellij with zero latency on is insane on Linux, I never noticed how slow it was until that point as I generally don't pay much attention to that stuff unless it's horribly slow.
This is related to a problem we have to deal with all the time in LaTeX - the delay between typing the source and seeing the typeset output, especially when running as a SaaS at https://www.overleaf.com
I think the quality of the output you're aiming for matters - we as authors (and I speak based on my experiences both running Overleaf and in writing research papers) seem to put up with more latency / compile delays if we feel it's 'worth it' (however badly defined) for what we're looking to produce.
I personally find I do my most creative writing late at night, but my most polished / error free during the day. Whilst I wish I could say I split my work up accordingly, I've never found a way to do this effectively. Anyone else have this / found a solution?
I used Classic theme in Windows because, as I pointed out earlier, Aero’s compositing increases drawing latency and enforces V-Sync.
This is an interesting datapoint in the argument between those who prefer the classic theme and those who use Aero, with proponents on both sides saying "it's faster". Perhaps compositing has higher throughput, but non-composited has lower latency. I personally use classic because it does feel more responsive. That extra ~15ms is definitely perceptible.
Another thing I've noticed is that when input latency is high, such as using SSH, I tend to keep typing ahead instead of waiting.
This is a really cool writeup. It's probably worth noting that humans don't notice latency under about 100ms and the table at the end shows all the editors surveyed coming in under that number. That said, I've noticed severe latency problems while trying out Atom, and almost never have problems with Vim (unless I try to edit a massive file in it). But for me the latency problems I notice usually aren't typing ones, but rather other interactions with the editor such as opening new files or trying to move around text.
You perceive sensory inputs within a 100ms window as occurring simultaneously. That does not mean that you cannot notice the difference between a 10ms latency and 50ms latency. Your may well perceive variations of latency, just not on a conscious level as a delay. The author asserts that high subliminal latency leads to higher discomfort and decreased productivity. I cannot find any studies on this right now, but it should be pretty straightforward to measure experimentally.
> Your may well perceive variations of latency, just not on a conscious level as a delay.
I agree. If you "want" to feel it consciously don't type text on a keyboard but play a melody on a midi keyboard. A latency of 10 ms, let alone 100 ms, feels horrible. For instance, a 1/16 note at 140 bpm has a duration of 107 ms!
I find it quite fascinating that recording midi in, say, cubase is possible at a lower latency than editing a text file in Atom.
I will always remember the smooth feel of an old SparcStation 20 I got in the late '00s. It was engineered so that hardware interrupts wouldn't get in each other's way. Regardless of the puny specs, the responsiveness was amazing, compared to any then-new x86 machine, where the console would stutter every time the OS felt like writing a large block to the hard drive.
It's a good point that a lot of editor latency issues aren't specific to typing. One thing that has always annoyed me is if an editor has slow find-and-replace for large files or projects.
I also find it interesting that you claim that humans don't notice latency under 100ms as though it is established fact, considering the OP spends basically the whole first section trying to debunk that incorrect but commonly quoted belief.
Not sure that's right. The threshold I've seen feels closer to 30ms, as in, needs to be under that even for casual users.
Note that even at 100 ms, most of the editors in the final graph are disqualified.
I would have loved to see a few more heavy ide such as visual studio and xcode and a few others. Though it was still quite great
Something very strange I've noticed: a bluetooth keyboard connected to my Mac doesn't have any perceptible latency... but the same keyboard connected to my iPad has extremely obvious latency (500ms or more.) Anyone know what the deal with that is? Do iOS devices sacrifice Bluetooth latency for battery life somehow?
What surprised me on the human side was how easy it was to learn another layout. So it seems that re-association is not the same thing as actually learning the keyboard the first time around. Watching the brain learn was a fun process. Would recommend it!
Went through this switching from a European layout to a US one, it took me around 4-5 days to be really comfortable with it, now it takes just a few minutes to switch between the two mentally.
Anyone have thoughts on keyboard switch type?
http://xahlee.info/kbd/keyboard_switch_mechanisms.html
Most keyboards (rubber dome, scissor) require the user to press a key to the bottom (i.e. A hard stop). Mechanical keyboards (e.g. spring, MX Cherry) register a keypress part way down. Cherry Blues, for example, have a pronounced sound and tactile feedback. Do these features make people better typist?