Hacker News Reader

> Let’s be honest, none of us are sitting around waiting for our complex IDEs to render characters on the screen. No one really cares if it’s 1ms or 30ms or even 200ms.

Waiting longer for a character to render to the screen than it takes to send an IP packet to a different continent and receive a reply may make you happy for some reason, but UI research indicates most people will react negatively to this.

It's worse than that. With something like Visual Studio, for example, we are sitting around waiting for local variables to update in the debugger's watch window, if we're experienced enough to know that we need to do that. This kind of thing is a genuine user interface bug: if a person doesn't realize what a slow, awful piece of software they're dealing with, they'll step step step past a variable update in the debugger, never see it happen on their screen because that only works when you pause and give the watch window time to catch up, and assume it's their program that has the problem.

People can get acclimated to dealing with very slow software, but they shouldn't have to when all the hardware performance to make it better already exists.

> No one really cares if it’s 1ms or 30ms or even 200ms.

You would definitely care about 200ms latency.

Have you looked at actual end-to-end latency numbers for common operations? I’m not talking about theoretical transfer times between buffers or carefully structured synthetic benchmarks.

Using fast-twitch PC games as the gold standard, most people are looking at 60-80ms of latency on a local PC. The online game streaming services hover around 150ms, which is noticeable but still entirely usable. (Source: https://www.pcgamer.com/heres-how-stadias-input-lag-compares... )

That’s why I say that 1ms vs 30ms of terminal latency is a non-issue. When I’m typing, I’m not on a tight feedback loop with each character. I know what I’m typing, so I’m not waiting for specific letters to appear on the order of a blink of an eye.

Most of us are using 60Hz monitors (17ms per frame) with terminals that have 20-30ms of lag, with OSes that introduce slightly more delay, and so on. Then we SSH into remote servers with 50ms, or 100ms, or 200ms of latency or more. The total delay between hitting a key and seeing the letter on screen could easily be 200ms on the regular for an SSH session, yet our typing isn’t falling apart.

That PC Gamer article is not an endorsement of the idea you're pushing that all this latency doesn't matter. "Singleplayer games are mostly fine to play through the cloud, but any cloud gaming platform is going to be a no-sell for people who only play multiplayer games, even with a good connection."

I don't want to give that magazine article too much credence, but when it comes to user experience, we as an industry ought to try for more than "mostly fine" or "isn't falling apart."

Typing at 100 wpm is a character about every 120 ms.

A 200 ms delay would be interoperable and a 30 ms delay would be a 25% penalty to see the characters appear.

Stella Pajunas 1946 record of 216 wpm (54,000 strokes per hour, 900 per min, 15 per second, 66 ms) is on average. She must have typed considerably faster some of the time. Anything over 40 ms is probably noticeable.

https://www.pond5.com/stock-footage/item/75268195-miss-stell...

Most wouldn't get near 1/3 of that but when the professionals say your shit doesn't work it does mean something. Trying to increase your speed using a system that cant keep up adds unacceptable annoyance.

I hereby coin the Pajunas rule at 40 ms.

> Let’s be honest, none of us are sitting around waiting for our complex IDEs to render characters on the screen. No one really cares if it’s 1ms or 30ms or even 200ms.

I actually do, because I'd like for IntelliSense and clones to save me some typing, but often that doesn't quite work out, because they're too slow (inconsistently slow, too). I'd also like it if my IDE or Word editor could highlight errors in realtime, but in reality it's more like a couple seconds delayed, so I have to navigate a significant distance back to correct them, instead of being able to fix it almost on the spot.

That’s a different topic, thought. The OP posted about typing latency, not the latency of additional complex features.

It’s not exactly fair to claim that software is “slower” than old software when the software you’re comparing to doesn’t have those features at all.

UI latency is UI latency, and the problem in both cases is due to what markstos mentioned in his initial comment: the increasing internal complexity of the software stack used to develop the software. It's not like modern hardware isn't fast enough to do literally everything that needs to be done locally with minimal UI latency.

I'm guessing 1000x

> Let’s be honest, none of us are sitting around waiting for our complex IDEs to render characters onLet’s be honest, none of us are sitting around waiting for our complex IDEs to render characters on the screen. the screen.

I see you are not much into modern IDEs.

Visual Studio used to be a great perpetrator here. The 2017 version doesn't do it much, but I'm not rolling the dice on the 2019 one as far as I can avoid.

I do sit around waiting for Atom to interpret my keystrokes all the time, but it's never much more than a couple of second.

Oracle's SQL Developer is another one that can't keep-up with the keyboard. It's also not as slow as Visual Studio, but it does break a flow. And it loses characters when it's blocked.

> Let’s be honest, none of us are sitting around waiting for our complex IDEs to render characters on the screen. No one really cares if it’s 1ms or 30ms or even 200ms.

You seem to never worked on ssh connection around the world. Typing faster than your text appears on the screen is annoying.

Or played with a 300 baud modem

> Let’s be honest, none of us are sitting around waiting for our complex IDEs to render characters on the screen. No one really cares if it’s 1ms or 30ms or even 200ms.

I do regularly on my 2019 MBP - I 'only' have the basic SSD and 'only' 16 gigs of memory. Usually Jetbrains stuff, but things freeze up/pause on VSCode and Eclipse as well too.

I'll then be told "oh, must be your hardware", but this is a "feature" I've noticed of... not just JVM software, but probably MacOS in general - sporadic system pauses. SSD makes it more bearable, certainly, but it's not "this" hardware - I've had probably 8 different mac systems since 2008, and they all do this. But... in the 15+ years of Windows and Linux systems before that, similar issues. I see it on other peoples' systems too, but they seem to be able to bite their tongue, or genuinely don't notice (or don't care?)

Are you talking pre 1980’s as early? Because IntelliJ vs EMACS is hardly a 100x improvement.

If you don't care, that is fine. But please don't spoil it for the ones caring. Don't argue against it if you don't care

> My IntelliJ IDE is easily 100 times more functional than early text editors.

Maybe more than text editors, but I doubt it's even twice as functional as eclipse circa 2005. As slow and bloated as it was for it's time it had all the modern features and ran on machines with (I think) 128MB of RAM.

The OOM killer regularly kills IntelliJ on my 16GB RAM Macbook pro when I have the audacity to leave it open while I try to compile something else. That really sucks, so I use vim whenever I'm familiar enough with the code to not need very intelligent autocompletion.

I can definitely feel the difference getting my terminal echoes over 40ms of latency and feel impeded. Not ridiculously impeded, but...