I/O is no longer the bottleneck? (2022) • Hacker News Board

Re: I/O is no longer the bottleneck? (2022)

#131

Post by _zoltan_ » Wed, Jan 07, 2026, 1:07 PM UTC

nine_k wrote: post #26

ThreatSystems wrote: post #16

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

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

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

Re: I/O is no longer the bottleneck? (2022)

#132

Post by coryrc » Wed, Jan 07, 2026, 5:31 PM UTC

zipy124 wrote: post #124

coryrc wrote: post #117

Earlier quoted context omitted.

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

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

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

Re: I/O is no longer the bottleneck? (2022)

#133

Post by brunoborges » Fri, Jan 09, 2026, 8:18 PM UTC

mort96 wrote: post #116

brunoborges wrote: post #105

Earlier quoted context omitted.

> This limit also applies to (de)serializing data like JSON and Protobuf, because those formats must typically be fully parsed before a single field can be read. Which file formats allow partial parsing?

You just need to encode the size of values in bytes to make it possible to partially parse the format. Imagine the following object: { "attributes": [ .. some really really long array of whatever .. ], "name": "Bob" } In JSON, if you want to extract the "name" property, you need to parse the whole "attributes" array. However, if you encoded the size of the "attributes" array in bytes, a parser could look at the key "…

Yeah, I was thinking of binary formats as the only solution, but your XML example is perfect. Thank you.