Hacker News Reader

Comment by amoss | Hacker News Reader

Why?

In 16.6ms a modern processor will execute about 128 million instructions. We need to locate about a screenful of text and/or cat pictures. We need to perform layout and then render it. The amount of work being done is not very much, or very difficult. The resources available are luxurious.

What part of the problem is it that makes it an unrealistic target?

View on HN

Because most screens are running at 16.6ms refresh rate, composition is vsynced and windows are double-buffered at multiple stages in the whole display pipeline to avoid tearing and other kinds of artifacts. You're naturally going to have 2-3 frames of latency unless you try really hard to avoid it with advanced frame scheduling that won't be worth employing (or maybe even feasible to employ) for an office application. You usually optimize application rendering for smoothness (no frame drops, no artifacts, consistent 60 FPS) rather than latency, and improving one usually hurts the other. And that's ignoring the input path, which brings its own latencies too.

Ah, ok so you are considering the latency rather than the throughput. I was thinking that being able to perform the update within 16.6ms should not be too hard - there is a sibling comment about SSD latency but the working set should fit in RAM.

Sure, so there will be latency, maybe 4-5 frames with input lag. But this is normally bearable in a game so I'm guessing that it would work fine for an office app. It would be difficult to remove, but 80ms response time from an application that can always hit its 16.6ms deadline should be workable.

We're talking about switching between conversations, latency is all that matters :)

This seems like needless pedantry. The computer should be able to easily do it in 16ms or less. Add on the 16ms or whatever of extra latency for the mouse and display, and it's fine.

Disk IO. Even with SSDs it's not that fast.

Reply on news.ycombinator.com