3 ms·

I disagree with this sentiment (I didn't downvote you though). Most serious terminal users are in fact concerned with millisecond latency. Consider also that t

by sgt 3y ago

I disagree with this sentiment (I didn't downvote you though). Most serious terminal users are in fact concerned with millisecond latency. Consider also that typing with 1ms additional latency per keystroke is noticable - even though it sounds counterintuitive. And note the other threads here with people noting that even the VS Code terminal can get very slow.

hnlmorg 3y ago
> I disagree with this sentiment (I didn't downvote you though). Most serious terminal users are in fact concerned with millisecond latency. SOME are concerned with millisecond latency, I agree. My point wasn't that there aren't users who care. It's that IF you care, then you shouldn't be using a multimedia terminal emulator. Putting rich content into the terminal will always add overhead. It doesn't matter if your terminal emulator is written in Electron or Rust, graphics is always going to be slower than text. So if you care about millisecond latency, then the problem with this terminal isn't the Electron part. I also disagree with your point that most serious terminal users care about millisecond latency. A lot probably do but I'm about as serious a terminal user can get; I've literally written and use my own shell because existing shells weren't powerful enough for me yet I didn't want to leave the terminal. The reason I don't care about millisecond latency is because you literally don't notice millisecond latency. More on that below. > Consider also that typing with 1ms additional latency per keystroke is noticable - even though it sounds counterintuitive. 1ms is literally imperceptive. There's plenty of evidence to back that up but I'll quote a SO answer: "The 100 ms threshold was established over 30 yrs ago. See: Card, S. K., Robertson, G. G., and Mackinlay, J. D. (1991). The information visualizer: An information workspace. Proc. ACM CHI'91 Conf. (New Orleans, LA, 28 April-2 May), 181-188. Miller, R. B. (1968). Response time in man-computer conversational transactions. Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267-277. Myers, B. A. (1985). The importance of percent-done progress indicators for computer-human interfaces. Proc. ACM CHI'85 Conf. (San Francisco, CA, 14-18 April), 11-17." source: https://stackoverflow.com/a/2547903 https://stackoverflow.com/a/2547903 > And note the other threads here with people noting that even the VS Code terminal can get very slow. ...under some very specific workflows. I literally explained that workflow in my post as well: "as long as the terminal reads from its PTY fast enough not to block those processes, which in all bar a very few edge cases it will be..." I do acknowledge that Electron is going to be slower than native code. Of course it's going to be slower. The question isn't whether Electron is as performant as native code, the actual point the GP made before their edit (a very cheeky edit on their part too) was that processes run slower in an Electron terminal. Which is horsehit in all bare a few edge cases.
- sgt 3y ago
  I played around with adding 1ms and 5ms etc to each keystroke and when typing very fast (e.g. 60-70wpm) you will definitely notice it. It's not even "imperceptive", it's in fact highly noticable. I guess I'll need to find a way to bring that hack back to life in order to show this to HN.
  - hnlmorg 3y ago
    what's the likelihood that your routine to make the delay isn't itself adding additional delay with the call overhead? I ask because this topic has been the subject of extensive scientific research already and their evidence doesn't back up your findings.
    - sgt 3y ago
      The scientific research you refer to is basically looking at the equialent of a single keypress, or a specific delay to a frame or similar. Once you have a whole burst of sequential keypresses with an interactive interface, it becomes very evident. I'll see what I can do in terms of the experiment.
      - noergl 3y ago
        Keyboarders are prolly the ppl with fastest trained finger action on earth, be it on a computer keyboard or a music keyboard. In digital music production there is a magic threshold of 15-20ms latency for input signals - if a signal takes longer to process through your DSPs/computers lineup, any good musician will start to perceive the latency (btw thats more like an on/off phenomenon). Below that range we cannot detect any latency chance anymore, as our neural system is not made for higher time resolution (also the reason why 60 FPS gives us the illusion of a movie). Typing latency on modern computers is really high compared to electronic or semi-digital typewriters of the 80s - those old machines had very little circuitry between the keypress and some output action, they were like hard-wired realtime machines to some degree. On today's machines there are tons of buffers, clocks, context switches etc. to pass, with no realtime promises anymore (at least not on typical consumer OS). We really have a "long line" in our machines today. Electron adds another buffer stack to this madness - the browser engine needs to get the PTY chunks somehow, which is often done with websockets as IPC. Which means put chunks into a http frame, send through network stack to the electron browser engine, decode there - and finally the terminal sees the data as input. A desktop TE does not have to go through that, it can simply write the PTY chunk to its data structures in the same process. Thats the real overhead happening for data IO intensive electron apps regarding input latency.

by sgt 3y ago

hnlmorg 3y ago

> I disagree with this sentiment (I didn't downvote you though). Most serious terminal users are in fact concerned with millisecond latency. SOME are concerned with millisecond latency, I agree. My point wasn't that there aren't users who care. It's that IF you care, then you shouldn't be using a multimedia terminal emulator. Putting rich content into the terminal will always add overhead. It doesn't matter if your terminal emulator is written in Electron or Rust, graphics is always going to be slower than text. So if you care about millisecond latency, then the problem with this terminal isn't the Electron part. I also disagree with your point that most serious terminal users care about millisecond latency. A lot probably do but I'm about as serious a terminal user can get; I've literally written and use my own shell because existing shells weren't powerful enough for me yet I didn't want to leave the terminal. The reason I don't care about millisecond latency is because you literally don't notice millisecond latency. More on that below. > Consider also that typing with 1ms additional latency per keystroke is noticable - even though it sounds counterintuitive. 1ms is literally imperceptive. There's plenty of evidence to back that up but I'll quote a SO answer: "The 100 ms threshold was established over 30 yrs ago. See: Card, S. K., Robertson, G. G., and Mackinlay, J. D. (1991). The information visualizer: An information workspace. Proc. ACM CHI'91 Conf. (New Orleans, LA, 28 April-2 May), 181-188. Miller, R. B. (1968). Response time in man-computer conversational transactions. Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267-277. Myers, B. A. (1985). The importance of percent-done progress indicators for computer-human interfaces. Proc. ACM CHI'85 Conf. (San Francisco, CA, 14-18 April), 11-17." source: https://stackoverflow.com/a/2547903 https://stackoverflow.com/a/2547903 > And note the other threads here with people noting that even the VS Code terminal can get very slow. ...under some very specific workflows. I literally explained that workflow in my post as well: "as long as the terminal reads from its PTY fast enough not to block those processes, which in all bar a very few edge cases it will be..." I do acknowledge that Electron is going to be slower than native code. Of course it's going to be slower. The question isn't whether Electron is as performant as native code, the actual point the GP made before their edit (a very cheeky edit on their part too) was that processes run slower in an Electron terminal. Which is horsehit in all bare a few edge cases.

sgt 3y ago
I played around with adding 1ms and 5ms etc to each keystroke and when typing very fast (e.g. 60-70wpm) you will definitely notice it. It's not even "imperceptive", it's in fact highly noticable. I guess I'll need to find a way to bring that hack back to life in order to show this to HN.
- hnlmorg 3y ago
  what's the likelihood that your routine to make the delay isn't itself adding additional delay with the call overhead? I ask because this topic has been the subject of extensive scientific research already and their evidence doesn't back up your findings.
  - sgt 3y ago
    The scientific research you refer to is basically looking at the equialent of a single keypress, or a specific delay to a frame or similar. Once you have a whole burst of sequential keypresses with an interactive interface, it becomes very evident. I'll see what I can do in terms of the experiment.
    - noergl 3y ago
      Keyboarders are prolly the ppl with fastest trained finger action on earth, be it on a computer keyboard or a music keyboard. In digital music production there is a magic threshold of 15-20ms latency for input signals - if a signal takes longer to process through your DSPs/computers lineup, any good musician will start to perceive the latency (btw thats more like an on/off phenomenon). Below that range we cannot detect any latency chance anymore, as our neural system is not made for higher time resolution (also the reason why 60 FPS gives us the illusion of a movie). Typing latency on modern computers is really high compared to electronic or semi-digital typewriters of the 80s - those old machines had very little circuitry between the keypress and some output action, they were like hard-wired realtime machines to some degree. On today's machines there are tons of buffers, clocks, context switches etc. to pass, with no realtime promises anymore (at least not on typical consumer OS). We really have a "long line" in our machines today. Electron adds another buffer stack to this madness - the browser engine needs to get the PTY chunks somehow, which is often done with websockets as IPC. Which means put chunks into a http frame, send through network stack to the electron browser engine, decode there - and finally the terminal sees the data as input. A desktop TE does not have to go through that, it can simply write the PTY chunk to its data structures in the same process. Thats the real overhead happening for data IO intensive electron apps regarding input latency.