5 ms·

Typing with pleasure

104 points by hhariri 11y ago

falcolas 11y ago
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.
- legulere 11y ago
  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.
  - gabesullice 11y ago
    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.
    - netmask 11y ago
      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
      - vegabook 11y ago
        +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.
  - copperx 11y ago
    No framebuffer, right? In my experience, the framebuffer introduces an annoying and noticeable delay.
- frankling 11y ago
  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.
  - ubercow13 11y ago
    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?
    - frankling 11y ago
      You're right, urxvt refreshes at a maximum of 60Hz (line 1021 in http://cvs.schmorp.de/rxvt-unicode/src/command.C?view=markup 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.
- barrkel 11y ago
  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.
jeffreyrogers 11y ago
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.
- delluminatus 11y ago
  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.
- rdancer 11y ago
  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.
  - cJ0th 11y ago
    > 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.
rdancer 11y ago
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 :-)
- geekone 11y ago
  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. [1] https://mosh.mit.edu/ https://mosh.mit.edu/
  - nickpsecurity 11y ago
    "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. :)
- simik 11y ago
  I found that in such cases it's actually more productive to close my eyes while typing.
- barrkel 11y ago
  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.
noir_lord 11y ago
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.
melling 11y ago
Anyone have thoughts on keyboard switch type? http://xahlee.info/kbd/keyboard_switch_mechanisms.html 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?
chubot 11y ago
Great 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) ... ?
- hueving 11y ago
  Try out mosh. Local buffers really make a difference for that latency.
  - chubot 11y ago
    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.
Namrog84 11y ago
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
smrq 11y ago
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.
ninjakeyboard 11y ago
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!
- FanaHOVA 11y ago
  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.
Derbasti 11y ago
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 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.
userbinator 11y ago
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.
derefr 11y ago
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?
JohnHammersley 11y ago
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 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?

104 points by hhariri 11y ago

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.

legulere 11y ago
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.
- gabesullice 11y ago
  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.
  - netmask 11y ago
    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
    - vegabook 11y ago
      +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.
- copperx 11y ago
  No framebuffer, right? In my experience, the framebuffer introduces an annoying and noticeable delay.
frankling 11y ago
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.
- ubercow13 11y ago
  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?
  - frankling 11y ago
    You're right, urxvt refreshes at a maximum of 60Hz (line 1021 in http://cvs.schmorp.de/rxvt-unicode/src/command.C?view=markup 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.
barrkel 11y ago
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.

jeffreyrogers 11y ago

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.

delluminatus 11y ago
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.
rdancer 11y ago
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.
- cJ0th 11y ago
  > 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.

rdancer 11y ago

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 :-)

geekone 11y ago
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. [1] https://mosh.mit.edu/ https://mosh.mit.edu/
- nickpsecurity 11y ago
  "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. :)
simik 11y ago
I found that in such cases it's actually more productive to close my eyes while typing.
barrkel 11y ago
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.

noir_lord 11y ago

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.

melling 11y ago

Anyone have thoughts on keyboard switch type? http://xahlee.info/kbd/keyboard_switch_mechanisms.html 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?

chubot 11y ago

Great 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) ... ?

hueving 11y ago
Try out mosh. Local buffers really make a difference for that latency.
- chubot 11y ago
  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.

Namrog84 11y ago

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

smrq 11y ago

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.

ninjakeyboard 11y ago

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!

FanaHOVA 11y ago
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.

Derbasti 11y ago

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 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.

userbinator 11y ago

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.

derefr 11y ago

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?

JohnHammersley 11y ago

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 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?