3 ms·

When people are used to virtually everything waiting on multiple round-trips over cellular connections, there's no point in optimizing local performance. An ext

by 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.
bartread 2y ago
> An extra hundred milliseconds of lag in the UI gets attributed to the slowness of the connection. This is looking at the problem wrong. I notice your shittily optimised application not just because it’s slow, but because it’s draining the battery. This is a problem, and developers need to wake up to it. Crappy performance uses more energy because the machine is doing unnecessary work to an end that could be achieved more efficiently, often much more efficiently. So, please, invest time in performance.
- kjellsbells 2y ago
  Alternate take: in a world where our entire society is trying to reduce energy usage, to minimize emissions, and so on, it strikes me as insanity that we do not demand every ounce of performance out of the hardware that we have, and equivalently, aim to minimize unnecessary demands on the hardware at the same time. Burning up a laptop CPU and torching racks of servers and routers in some data center just because the web is full of shitty ui frameworks should be intolerable to consumers and providers. Efficiency really needs to be a goal of all system designers.
  - paulddraper 2y ago
    What UI framework do you like to use?

by dkarl 2y ago

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.

bartread 2y ago

> An extra hundred milliseconds of lag in the UI gets attributed to the slowness of the connection. This is looking at the problem wrong. I notice your shittily optimised application not just because it’s slow, but because it’s draining the battery. This is a problem, and developers need to wake up to it. Crappy performance uses more energy because the machine is doing unnecessary work to an end that could be achieved more efficiently, often much more efficiently. So, please, invest time in performance.

kjellsbells 2y ago
Alternate take: in a world where our entire society is trying to reduce energy usage, to minimize emissions, and so on, it strikes me as insanity that we do not demand every ounce of performance out of the hardware that we have, and equivalently, aim to minimize unnecessary demands on the hardware at the same time. Burning up a laptop CPU and torching racks of servers and routers in some data center just because the web is full of shitty ui frameworks should be intolerable to consumers and providers. Efficiency really needs to be a goal of all system designers.
- paulddraper 2y ago
  What UI framework do you like to use?