6 ms·

I'm old enough to remember when speed was the defining factor for everything. Benchmarks were a critical part if selling, everyone knew the mhz of their cpu, sp

I'm old enough to remember when speed was the defining factor for everything. Benchmarks were a critical part if selling, everyone knew the mhz of their cpu, speed was the most important thing, it was the only thing. And I'm not talking about techies, I'm talking about the man in the street. Today, all computers, all programs are "fast enough". Most people can't name a benchmark, much less use it for comparison. Computer sales seldom focus on mhz. Your phone is either fast or slow. But actual measures are not what phone users care about. These days it's all about capability. Most of which is assumed to exist as table stakes, and which didn't even exist in Windows 95 days. Maybe people under-estimate how fast their PC is, but equally they grossly underestimate how much work it -is- doing. Some, but not huge, amounts of time are spent on making things "as fast as they can be". Because customers are paying for more capability, not more speed.

lazide 2y ago
UI latency has gotten horrendous, both desktop and web. That is what people are experiencing - 500ms-3000ms delays for basic UI interactions (or more), frozen UI’s, jerky/laggy autocomplete and UI renders. Like the classic ‘button is a different button by the time you see the old button and click on it’. On incredibly lightly loaded and overpowered hardware. Everyone has been focused on some core algorithm, and completely ignoring the user experience. IMO.
- lucasmullens 2y ago
  I remember learning that you get about 100ms for a basic UI interaction before a user perceives it as slow. And you get about 1s for a "full page navigation", even if it's a SPA, users are a bit more understanding if you're loading something that feels like new page. Getting under 100ms really shouldn't be hard for most things. At the very least it should be easy to get the ripple (or whatever button animation) to trigger within the first 100ms.
  - lazide 2y ago
    Usually these issues are caused by doing work in the UI thread (easy, when it’s ‘cheap’) synchronously. All UI thread frameworks end up doing the UI interactions on a single thread, or everything becomes impossible to manage, and especially if not careful, it’s easy to not properly setup an async callout or the like with the correct callbacks. It is easy to make a responsive, < 100 ms UI, it’s often harder to keep it that way.
  - delta_p_delta_x 2y ago
    It is mental just how different the video game and (web/desktop front-end) realms are. In the former, one can have a complicated and dynamic three-dimensional scene with millions of polygons, gigabytes of textures, sprites, and other assets being rasterised/path-traced, as well as real-time spatial audio to enhance the experience, and on top of that a real-time 2D UI which reflects the state of the aforementioned 3D scene, all composited and presented to the monitor in ~10 ms. And this happens correctly and repeatedly, frame after frame after frame, allowing gamers to play photorealistic games at 4K resolution at hundreds of frames a second. In the latter, we have 'wew bubble animation and jelly-like scroll, let's make it 300 ms long'. 300 ms is rubbish enough ping to make for miserable experiences in multiplayer games, but somehow this is OK in UIs.
    - npunt 2y ago
      Agree it's like two separate worlds. Games and web aren't 1:1 tho in relation to whether visual responsiveness is blocking a task. Games need ultra-responsiveness because rendering frames slower is essentially blocking further user interaction, since players are expected to provide a constant stream of interaction. Being 'engaged' is essentially requiring constant feedback loops between input/output. On the web the task of reading a webpage doesn't require constant engagement like in games. UI (should) behave in more predictable ways where animation is only there to draw association, not provide novel info. Similarly UI animations are typically (or should not be) blocking main thread responsiveness and (should be) interruptible, so even low frame rates are not breaking the experience in the same way. But still, your point stands, its crazy what we've come to accept.
      - crest 2y ago
        I also expect my everyday tools to be responsive e.g. if a "desktop" application lags while typing I'm uninstalling that shit (if there is an alternative sigh).
        PlunderBunny 2y ago
        I find VS Code unusable for this reason - typing is like communicating with an app in a parallel world.
- AgentOrange1234 2y ago
  I wonder to what degree people are actually experiencing this. I'm on a 5-year old intel Macbook, and I think in my daily experience, core software (browsers, emacs, keynote, music) are pretty snappy. I do routinely work with some extremely frustratingly slow software, but it's pretty stark how much its performance stands out as, well... exceptionally bad.
- ssl-3 2y ago
  UI lag is a problem, for sure -- and so are some of the dynamic layouts that are meant to "solve" it[1]. One thing I've noticed lately is mouse lag. Like, say, in Ye Olde Start Menu on Windows: Move the mouse to the Start menu, and press the mouse button down. Nothing happens. Release the button, and then: Something happens. The menu is triggered on button-up events, not button-down events. This adds a measurable delay to every interaction. Same with Chrome when clicking on a link: Nothing happens until the button is released. This adds a delay. I mean: Go ahead and try it right now. I'll wait. And sure, it might be a small delay: After all, it can't be more than a few milliseconds per click, right[2]? But even though the delay is small, it is something that is immediately obvious when opening the "Applications" menu in XFCE 4, wherein: The menu appears seemingly-instantly when the mouse button is first pushed down. [1]: It took me more than three tries to pick a streaming device from Plex on my phone yesterday. I'd press the "cast" button, and a dynamic list of candidate devices would show up. I'd try to select the appropriate candidate and before my thumb could move the fraction of an inch to push the button, the list had changed as more candidate devices were discovered -- so the wrong device was selected. So I then had to dismantle the stream that I'd just started on the wrong device, and try (and fail) again. [2]: But even small delays add up. Let's say this seemingly-unoptimized mouse operation costs an average of 3ms per click. And that 100 million people experience this delay, 100 times each, per day. That's nearly an entire year (347 days) of lost human time for the group per day, or 347 years lost per year. Which is 4.4 human lifetimes, per year that are lost within the group of 100 million, just because we're doing mouse events lazily.
  - teddyh 2y ago
    Which, if any, GUIs have ever activated anything decisive on mousebutton-down events? IIRC, everyone uses mousebutton-up events as the imperative factor.
    - ssl-3 2y ago
      XFCE 4 is that way for most things that I've tried right now: The menu panels and desktop context menus work on button-down. Switching Chrome tabs works on button-down. Activating the three-dot menu in Chrome also works on button-down (which is good) but then it needlessly fades from 0% to 100% opacity (which is a crime against nature). I didn't even have to go digging in the memory hole to find this. It's right here in front of me.
- EasyMark 2y ago
  The only time I see delays like that is when there is something that has to happen like a network data fetch, database lookup, etc. I’ve written a ton of GUIs in javascript/python and they’re all indistinguishable from c++ qt apps I’ve written, basically faster than a human can hope to do another operation short of queuing up keyboard commands via a “keyboard only” interop (say in emacs). When I’ve seen slowness like the latency was always per what I said before data fetch in some format from a slow database/network connection
  - procflora 2y ago
    No doubt I'm picking an easy target here, but it takes like 700 ms to switch back and forth from the Chat tab to the Calendar tab in the Teams desktop client on my boring work-issued laptop (i.e. commodity hardware). This is repeatable, first time, every time. It doesn't even bother to animate anything or give feedback that a UI interaction has occurred until 500+ ms after the click. Some things do run very quickly, for sure, but so many of the high touch pieces of code out there from big name corps have some of the worst performance. Hundreds of millions of people use Teams, and many of them use it a lot throughout the day. You must just be getting lucky in what apps you use on a regular basis.
    - lazide 2y ago
      I think they’re referring to actual implementation, which in their experience would require some sort of massive architectural stupidity to produce a slow UI on desktop. And you’re referring to your (and most other people’s) daily experience, which is of a major software firm producing daily used software with a super slow UI on desktop. With a little cynicism, these two views are quite compatible.
- int_19h 2y ago
  > button is a different button by the time you see the old button and click on it This is somewhat exacerbated by, ironically, UI mostly being async these days. Back then, if app was slow, it would usually block the UI thread outright, so you couldn't click anything until processing was done. But these days UI is usually "responsive" in a sense that you can interact with it, and lag instead manifests by UI getting out of sync with the actual state (and constantly trying to catch up with it, causing the problem you describe).
- kaba0 2y ago
  I think this problem is a bit overblown, as we tend to get very angry at the relatively few offending ones, and fail to notice the case where it just works. So might be just some human bias over-amplification. Like, there are websites that absolutely suck, but that’s mostly due to some idiotic management decision to add 4 different tracking bullshit libraries, and download 6 ads per click. Thinking about the regular software I use.. could it be better? Certainly. But it is very far from unusable.
renegade-otter 2y ago
So this isn't just me. I thought I was getting more impatient, but performance does seem to be degrading as it's no longer considered to be a feature. There is absolutely ZERO reason why a modern operating system or some rudimentary site with 10K users should not be blazing fast. I have to constantly close my browser on a 12-core Intel Mac MINI just because four open sites get its fan spinning like it's a Hoover Dam turbine.
- dkarl 2y ago
  When people are used to virtually everything waiting on multiple round-trips over cellular connections, there's no point in optimizing local performance. An extra hundred milliseconds of lag in the UI gets attributed to the slowness of the connection. Plus web and mobile developers have put a ton of work into animations and things like that to make slowness feel natural, which lowers expectations even further. Nobody expects a device to respond quickly. You expect to have to wait a bit for round-trips or animations or both.
  - npunt 2y ago
    On the other hand, in a world of slightly non-responsive software, something that does respond instantly has a subconscious psychological impact on us and builds affinity.
    - renegade-otter 2y ago
      Indeed. I cover this in "Your Database Skills Are Not 'Good to Have'": https://renegadeotter.com/2023/11/12/your-database-skills-are-not-good-to-have.html https://renegadeotter.com/2023/11/12/your-database-skills-ar... Specifically when I cite THIS: https://designingforperformance.com/performance-is-ux/ https://designingforperformance.com/performance-is-ux/
      - paulmd 2y ago
        > Imagine if SELECT field1, field2 FROM my_table was faster than SELECT field2, field1 FROM my_table. possibly it might not be smart enough to reorder an index on (field1, field2), or it had some weird internal constraint on tuple ordering, or it was simply different enough to go down a different query plan sometimes, or maybe there’s something around the actual physical ordering on disk? but yeah postgres and SQLite are modern marvels that we take for granted… myISAM was not a good time, or at least people tended to violate the correctness/visibility rules it promised (iirc) or something like that. The fact that you can just open up a stable, well-tested sql instance that runs against disk, or drop Postgres into most transactional use-cases, and generally not have to worry about unduly fighting the DB itself, is underappreciated.
koito17 2y ago
> Computer sales seldom focus on mhz. For good reason. Clock speed isnt the sole factor in performance. A PowerPC 970 can clock up to 2 GHz, but it only achieves 8 instructions per cycle (on average!) for arithmetic instructions. Modern mobile CPUs clocked at a fraction of 2 GHz achieve much higher throughput for arithmetic. The branch predictor in the PPC chip, while impressive for its time, is simple in comparison to those of modern processors. A CPU without pre-fetching is going to have much worse latency and throughput than any CPU with it. So on, so forth. Overall, it's naive at best to focus on clock speed for performance. I used to fixate on it when I was a teenager, but not anymore.
- fanf2 2y ago
  8 instructions per cycle is a lot, especially on average! I checked and the PPC 970 could fetch, decode, and issue at most 8 ALU ops per cycle, but it could only retire 5 instructions per cycle, so its average IPC is probably less than 4. https://www.anandtech.com/show/1702/2 https://www.anandtech.com/show/1702/2
  - userbinator 2y ago
    8 RISC instructions per cycle is much easier to achieve than CISC ones.
- crest 2y ago
  If only the the PPC 970 was able to sustain an IPC of eight... it would've been a true miracle to run at 2GHz in 130nm (later 90nm). An IPC of ≥8 for more than a few cycles is something you'll only see during unrealistic micro-benchmarks (e.g. those used to reverse engineer their micro-architecture limits) on the widest of modern out-of-order CPU cores. To really sustain such an IPC in a real-world application workload you still need unusual applications and hardware e.g. a really wide VLIW DSP and *well* *optimised* assembler code.
HPsquared 2y ago
It's the same with cars. Manufacturers have long since made cars that are "fast enough" and it's less of a differentiator then it used to be.
- bongodongobob 2y ago
  Not really, top speed has never been a selling point for cars since maybe the bootlegging days. They've been optimizing for either power or gas mileage for a long time.
  - fire_lake 2y ago
    No, they are optimized for status signalling.

lazide 2y ago

UI latency has gotten horrendous, both desktop and web. That is what people are experiencing - 500ms-3000ms delays for basic UI interactions (or more), frozen UI’s, jerky/laggy autocomplete and UI renders. Like the classic ‘button is a different button by the time you see the old button and click on it’. On incredibly lightly loaded and overpowered hardware. Everyone has been focused on some core algorithm, and completely ignoring the user experience. IMO.

lucasmullens 2y ago
I remember learning that you get about 100ms for a basic UI interaction before a user perceives it as slow. And you get about 1s for a "full page navigation", even if it's a SPA, users are a bit more understanding if you're loading something that feels like new page. Getting under 100ms really shouldn't be hard for most things. At the very least it should be easy to get the ripple (or whatever button animation) to trigger within the first 100ms.
- lazide 2y ago
  Usually these issues are caused by doing work in the UI thread (easy, when it’s ‘cheap’) synchronously. All UI thread frameworks end up doing the UI interactions on a single thread, or everything becomes impossible to manage, and especially if not careful, it’s easy to not properly setup an async callout or the like with the correct callbacks. It is easy to make a responsive, < 100 ms UI, it’s often harder to keep it that way.
- delta_p_delta_x 2y ago
  It is mental just how different the video game and (web/desktop front-end) realms are. In the former, one can have a complicated and dynamic three-dimensional scene with millions of polygons, gigabytes of textures, sprites, and other assets being rasterised/path-traced, as well as real-time spatial audio to enhance the experience, and on top of that a real-time 2D UI which reflects the state of the aforementioned 3D scene, all composited and presented to the monitor in ~10 ms. And this happens correctly and repeatedly, frame after frame after frame, allowing gamers to play photorealistic games at 4K resolution at hundreds of frames a second. In the latter, we have 'wew bubble animation and jelly-like scroll, let's make it 300 ms long'. 300 ms is rubbish enough ping to make for miserable experiences in multiplayer games, but somehow this is OK in UIs.
  - npunt 2y ago
    Agree it's like two separate worlds. Games and web aren't 1:1 tho in relation to whether visual responsiveness is blocking a task. Games need ultra-responsiveness because rendering frames slower is essentially blocking further user interaction, since players are expected to provide a constant stream of interaction. Being 'engaged' is essentially requiring constant feedback loops between input/output. On the web the task of reading a webpage doesn't require constant engagement like in games. UI (should) behave in more predictable ways where animation is only there to draw association, not provide novel info. Similarly UI animations are typically (or should not be) blocking main thread responsiveness and (should be) interruptible, so even low frame rates are not breaking the experience in the same way. But still, your point stands, its crazy what we've come to accept.
    - crest 2y ago
      I also expect my everyday tools to be responsive e.g. if a "desktop" application lags while typing I'm uninstalling that shit (if there is an alternative sigh).
      - PlunderBunny 2y ago
        I find VS Code unusable for this reason - typing is like communicating with an app in a parallel world.
AgentOrange1234 2y ago
I wonder to what degree people are actually experiencing this. I'm on a 5-year old intel Macbook, and I think in my daily experience, core software (browsers, emacs, keynote, music) are pretty snappy. I do routinely work with some extremely frustratingly slow software, but it's pretty stark how much its performance stands out as, well... exceptionally bad.
ssl-3 2y ago
UI lag is a problem, for sure -- and so are some of the dynamic layouts that are meant to "solve" it[1]. One thing I've noticed lately is mouse lag. Like, say, in Ye Olde Start Menu on Windows: Move the mouse to the Start menu, and press the mouse button down. Nothing happens. Release the button, and then: Something happens. The menu is triggered on button-up events, not button-down events. This adds a measurable delay to every interaction. Same with Chrome when clicking on a link: Nothing happens until the button is released. This adds a delay. I mean: Go ahead and try it right now. I'll wait. And sure, it might be a small delay: After all, it can't be more than a few milliseconds per click, right[2]? But even though the delay is small, it is something that is immediately obvious when opening the "Applications" menu in XFCE 4, wherein: The menu appears seemingly-instantly when the mouse button is first pushed down. [1]: It took me more than three tries to pick a streaming device from Plex on my phone yesterday. I'd press the "cast" button, and a dynamic list of candidate devices would show up. I'd try to select the appropriate candidate and before my thumb could move the fraction of an inch to push the button, the list had changed as more candidate devices were discovered -- so the wrong device was selected. So I then had to dismantle the stream that I'd just started on the wrong device, and try (and fail) again. [2]: But even small delays add up. Let's say this seemingly-unoptimized mouse operation costs an average of 3ms per click. And that 100 million people experience this delay, 100 times each, per day. That's nearly an entire year (347 days) of lost human time for the group per day, or 347 years lost per year. Which is 4.4 human lifetimes, per year that are lost within the group of 100 million, just because we're doing mouse events lazily.
- teddyh 2y ago
  Which, if any, GUIs have ever activated anything decisive on mousebutton-down events? IIRC, everyone uses mousebutton-up events as the imperative factor.
  - ssl-3 2y ago
    XFCE 4 is that way for most things that I've tried right now: The menu panels and desktop context menus work on button-down. Switching Chrome tabs works on button-down. Activating the three-dot menu in Chrome also works on button-down (which is good) but then it needlessly fades from 0% to 100% opacity (which is a crime against nature). I didn't even have to go digging in the memory hole to find this. It's right here in front of me.
EasyMark 2y ago
The only time I see delays like that is when there is something that has to happen like a network data fetch, database lookup, etc. I’ve written a ton of GUIs in javascript/python and they’re all indistinguishable from c++ qt apps I’ve written, basically faster than a human can hope to do another operation short of queuing up keyboard commands via a “keyboard only” interop (say in emacs). When I’ve seen slowness like the latency was always per what I said before data fetch in some format from a slow database/network connection
- procflora 2y ago
  No doubt I'm picking an easy target here, but it takes like 700 ms to switch back and forth from the Chat tab to the Calendar tab in the Teams desktop client on my boring work-issued laptop (i.e. commodity hardware). This is repeatable, first time, every time. It doesn't even bother to animate anything or give feedback that a UI interaction has occurred until 500+ ms after the click. Some things do run very quickly, for sure, but so many of the high touch pieces of code out there from big name corps have some of the worst performance. Hundreds of millions of people use Teams, and many of them use it a lot throughout the day. You must just be getting lucky in what apps you use on a regular basis.
  - lazide 2y ago
    I think they’re referring to actual implementation, which in their experience would require some sort of massive architectural stupidity to produce a slow UI on desktop. And you’re referring to your (and most other people’s) daily experience, which is of a major software firm producing daily used software with a super slow UI on desktop. With a little cynicism, these two views are quite compatible.
int_19h 2y ago
> button is a different button by the time you see the old button and click on it This is somewhat exacerbated by, ironically, UI mostly being async these days. Back then, if app was slow, it would usually block the UI thread outright, so you couldn't click anything until processing was done. But these days UI is usually "responsive" in a sense that you can interact with it, and lag instead manifests by UI getting out of sync with the actual state (and constantly trying to catch up with it, causing the problem you describe).
kaba0 2y ago
I think this problem is a bit overblown, as we tend to get very angry at the relatively few offending ones, and fail to notice the case where it just works. So might be just some human bias over-amplification. Like, there are websites that absolutely suck, but that’s mostly due to some idiotic management decision to add 4 different tracking bullshit libraries, and download 6 ads per click. Thinking about the regular software I use.. could it be better? Certainly. But it is very far from unusable.

renegade-otter 2y ago

So this isn't just me. I thought I was getting more impatient, but performance does seem to be degrading as it's no longer considered to be a feature. There is absolutely ZERO reason why a modern operating system or some rudimentary site with 10K users should not be blazing fast. I have to constantly close my browser on a 12-core Intel Mac MINI just because four open sites get its fan spinning like it's a Hoover Dam turbine.

dkarl 2y ago
When people are used to virtually everything waiting on multiple round-trips over cellular connections, there's no point in optimizing local performance. An extra hundred milliseconds of lag in the UI gets attributed to the slowness of the connection. Plus web and mobile developers have put a ton of work into animations and things like that to make slowness feel natural, which lowers expectations even further. Nobody expects a device to respond quickly. You expect to have to wait a bit for round-trips or animations or both.
- npunt 2y ago
  On the other hand, in a world of slightly non-responsive software, something that does respond instantly has a subconscious psychological impact on us and builds affinity.
  - renegade-otter 2y ago
    Indeed. I cover this in "Your Database Skills Are Not 'Good to Have'": https://renegadeotter.com/2023/11/12/your-database-skills-are-not-good-to-have.html https://renegadeotter.com/2023/11/12/your-database-skills-ar... Specifically when I cite THIS: https://designingforperformance.com/performance-is-ux/ https://designingforperformance.com/performance-is-ux/
    - paulmd 2y ago
      > Imagine if SELECT field1, field2 FROM my_table was faster than SELECT field2, field1 FROM my_table. possibly it might not be smart enough to reorder an index on (field1, field2), or it had some weird internal constraint on tuple ordering, or it was simply different enough to go down a different query plan sometimes, or maybe there’s something around the actual physical ordering on disk? but yeah postgres and SQLite are modern marvels that we take for granted… myISAM was not a good time, or at least people tended to violate the correctness/visibility rules it promised (iirc) or something like that. The fact that you can just open up a stable, well-tested sql instance that runs against disk, or drop Postgres into most transactional use-cases, and generally not have to worry about unduly fighting the DB itself, is underappreciated.

koito17 2y ago

> Computer sales seldom focus on mhz. For good reason. Clock speed isnt the sole factor in performance. A PowerPC 970 can clock up to 2 GHz, but it only achieves 8 instructions per cycle (on average!) for arithmetic instructions. Modern mobile CPUs clocked at a fraction of 2 GHz achieve much higher throughput for arithmetic. The branch predictor in the PPC chip, while impressive for its time, is simple in comparison to those of modern processors. A CPU without pre-fetching is going to have much worse latency and throughput than any CPU with it. So on, so forth. Overall, it's naive at best to focus on clock speed for performance. I used to fixate on it when I was a teenager, but not anymore.

fanf2 2y ago
8 instructions per cycle is a lot, especially on average! I checked and the PPC 970 could fetch, decode, and issue at most 8 ALU ops per cycle, but it could only retire 5 instructions per cycle, so its average IPC is probably less than 4. https://www.anandtech.com/show/1702/2 https://www.anandtech.com/show/1702/2
- userbinator 2y ago
  8 RISC instructions per cycle is much easier to achieve than CISC ones.
crest 2y ago
If only the the PPC 970 was able to sustain an IPC of eight... it would've been a true miracle to run at 2GHz in 130nm (later 90nm). An IPC of ≥8 for more than a few cycles is something you'll only see during unrealistic micro-benchmarks (e.g. those used to reverse engineer their micro-architecture limits) on the widest of modern out-of-order CPU cores. To really sustain such an IPC in a real-world application workload you still need unusual applications and hardware e.g. a really wide VLIW DSP and *well* *optimised* assembler code.

HPsquared 2y ago

It's the same with cars. Manufacturers have long since made cars that are "fast enough" and it's less of a differentiator then it used to be.

bongodongobob 2y ago
Not really, top speed has never been a selling point for cars since maybe the bootlegging days. They've been optimizing for either power or gas mileage for a long time.
- fire_lake 2y ago
  No, they are optimized for status signalling.