[ThreatSystems]

*Unless your in the cloud, then it's a metric to nickel and dime with throttling!

On a more serious note, the performance of hardware today is mind boggling from what we all encountered way back when. What I struggle to comprehend though is how some software (particularly Windows as an OS, instant messaging applications etc.) feel less performant now than they ever were.

[rsanheim]

The performance of hardware today is even more mind-boggling compared to what most people (SRE managers, devs, CTOs) are willing to pay for when it comes to cloud compute.

even more so when considered in the context of dev 'remote workstations'. I benchmarked perf on AWS instances that was at least 5x slower than an average m1 macbook, and cost hundreds of dollars a dev per month (easily), and the macbook was a sunk cost!

[nine_k]

The answer, I suspect, is is the same as always: waiting for I/O in the GUI thread.

Both Telegram and FB messenger are snappy; I didn't use anything else seriously as of late. (Especially not Teams, nor the late Skype.)

[josephg]

> waiting for I/O in the GUI thread

The problem is sloppy programming. We knew how to make small, fast, programs 20+ years ago that would just scream on modern hardware. But now everything is bloated and slow. CPUs can retire billions of instructions per second. Discord takes 10+ seconds to open. I’m simply not creative enough to think up how to keep the cpu busy that long opening IRC.

[eru]

Moore's law really help you with throughput, but latency still requires good engineering.

And you are right, that we got good UI latency even back in the 1980s. You just have make sure that you do the absolute minimum amount of work possible in the UI 'thread' and do gradual enhancement as more time passes.

As an example, the Geos word processor on the C64 does nice line breaks at the end of words only. But if you type really fast, it just wraps lines when you hit exactly x letters, and later when it has some time to catch up, it cleans up the line breaks.

That way it can give you a snappy user experience even on a comically underpowered system. But you can also see that the logic is much more complicated, than just implementing a single business logic for where line breaks should be. Complication means more bugs, more time spent writing and debugging and documenting etc.

[fragmede]

They could be way faster. They're snappy enough but still, so slow.

[_zoltan_]

FB messenger was so good, but they've killed it on both Windows and Mac and I'm sad about it :(

they are forcing me to use the web client...

[coryrc]

CRTs get data to the screen faster. Some LCDs have 500ms delays.

[zipy124]

What non-ancient LCD's have response times that high. Even e-ink/e-paper displays are better than that!

[coryrc]

TVs can do a bunch of filtering which adds long latency based on the setting about the type of content (sorry, can't remember the exact term ATM).

[zipy124]

That is true, but the worst offenders are about 300ms, and out of the 515 rtings have tested, only 5 have a worst case more than 200ms. A typical 'bad' LCD would be somewhere closer to 50-100ms usually.

https://www.rtings.com/tv/tests/inputs/input-lag

[coryrc]

First, the oldest TV on their list is from 2020. Second, they didn't seem to test in the other "smoothing" input modes (because why would you if you're looking for low input latency as opposed to an uninformed consumer just using arbitrary settings?)

A CRT's latency starts at ZERO, depending on what's driving it and when the input is received ("racing the beam").