Let's be realistic, it would be pretty hard to hit 16.6ms. Not impossible, but very complex with little benefit (at this point you need to care about such low-level things as the way you schedule frames to be displayed by system compositor, for example - and even how the compositor itself is doing its work too!). Something like 200ms, however, should be perfectly achievable with little effort and just as snappy in practice for this kind of app :)

(note that a game running at 60 FPS does not mean that you get 16.6ms mouse-to-screen latency at all)

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?

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 for an office application. You usually optimize application rendering for smoothness (no frame drops, no artifacts, consistent 60 FPS) rather than latency, and doing one usually hurts the other.

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.

>> it would be pretty hard to hit 16.6ms

Hard disagree. Sorry, but rant inc ...

If we can't hit 60fps with a chat app, one of the simplest applications imaginable by man, what the hell can we hit 60 with? It's drawing a couple thousand triangles (maybe) with a couple hundred textures (I guess). Game engines fart a couple thousand triangles when they're done drawing 50x+ that. Oh, and they do about a gazillion other operations .. at 60fps+

The slow part of switching between conversations is fetching the data which, on a fiber connection in a city, is < 5ms round trip. Hell, I live in the boonies in Canada and my round trip to Seattle is only like 20ms. You could also cache the first 20 messages to every conversation (disk space is cheap) to avoid the network.

As for the notion that "you need to care about such low-level things ...", yes, you do. To write fast software you just deal with it and move on.

Being able to hit 60fps is just a single prerequisite for low latency, but it's far from enough. The application may be able to render itself consistently even in 2ms just fine, but effect of your action won't appear on the screen until much later unless you make your whole stack (including the OS) surprisingly complex (which is worth doing in case of competitive video games running in fullscreen, not for applications).

Seems like you're simply not aware of complexities of the display path. Please make a simple windowed OpenGL application displaying a single triangle in thousands FPS that changes color when you press a key and measure its latency, you may be surprised ;)

Okay, I see what you're getting at now, and yes, there are a few frames of latency between the time the app is done drawing and the time pixels are in front of your eyeballs, but that is _completely_ missing my point, and the point of the tweet.

If we're splitting hairs about how we define how long an application takes to update, we've already won.

In reality, we're talking about an app that should take ~0.01s to perform an operation (update a rectangular region with text), that's taking 1.0s instead. And that's THE OPTIMIZED VERSION. In the real world, we've already lost, which is what Casey was pointing out in his tweet.

The only measure the user cares about when it comes to snappiness is input-to-display latency, and the whole point of my comment was to be realistic about it. A chat app won't hit 16.6ms latency, but it doesn't have to. 100-200ms is realistic and perfectly fine, and if you don't manage to hit it, something is seriously wrong with your application.

And yes, of course, something is seriously wrong with a lot of applications these days, otherwise we wouldn't be having this conversation at all.

I’ve heard Safari doesn’t allow performance regressions. And they currently have the fastest browser.

From the horse's mouth: https://twitter.com/rniwa_dev/status/1578097561222537216 (a mini thread, only quoting top tweet)

"It's a bit of understatement to say @WebKit project cares about performance or efficiency of the software. We're quite obsessed with it, and we throw a lot of engineering resources at it, not to regress, and to improve upon."