6 ms·

A theory I've often had: the Jevons paradox explains why desktop software remains so slow despite the massive improvements in hardware speeds. When you improve

A theory I've often had: the Jevons paradox explains why desktop software remains so slow despite the massive improvements in hardware speeds. When you improve the efficiency of the hardware, software starts to demand more CPU cycles, since there's less of an incentive to optimize.

awb 5y ago
> When you improve the efficiency of the hardware, software starts to demand more CPU cycles, since there's less of an incentive to optimize. Or rather, there’s always more work to be done.
- gus_massa 5y ago
  For example the orthographic and grammatical correction. When I was young, the browser didn't have it. Now it fix most of my post in HN.
  - awb 5y ago
    *fixes
  - deleted 5y ago
    [deleted]
Syonyk 5y ago
> ...software starts to demand more CPU cycles, since there's less of an incentive to optimize. Node and Electron and crew would agree. A "modern" chat client (Element, Signal, etc) will lag on a quad core 1.5GHz system in terms of "typing into the text input box" (RasPi4, yes, I've set the governor to performance), when a single core 66MHz 486 could manage that trick without any lag in a range of chat clients. Hexchat still works fine, at least. What we need to do is stop letting developers use high end, modern systems, and put them on something a decade old for daily use. Then maybe they'll stop writing crap that only works well on a 1-2 year old Xeon workstation. Google, I'm looking at you. Buy all your devs a Pi4 and make them use it once a week for a day.
- api 5y ago
  Some of it is explained by bloat but some of it is explained by things like 4K-5K displays, pretty antialiased fonts, support for multiple languages and unicode, support for inline images and videos, emojis, support for all kinds of inline objects like polls or HTML documents, transport encryption everywhere (sometimes multiple layers of it like Signal ratchet over TLS), scrollback history with search going back to the beginning of time, real time sync between devices, and so on. High resolution displays for example impose an exponential cost right out of the gate. Just printing "hello world" requires more pixels as a function of the square of the increase in resolution. That's more memory, more memory bus traffic, larger bitmaps, scalable vector graphics formats that take more processing power to draw, antialiasing, ... Again I am not writing off bloat. We could probably shrink most software by at least 2X and most Electron stuff by 3-4X. I doubt we could shrink it 10-100X though without sacrificing some of the things I listed up there, especially all the eye candy and rich interaction media.
  - Syonyk 5y ago
    In my particular context, it's a Raspberry Pi on a 1920x1200 display, 1:1 pixel scaling, no antialising I know of, and... the rest shouldn't matter that much in terms of how long it takes a key pressed at the keyboard to show up in the input text area. If it does, something is quite wrong in the architecture, IMO, and it's probably 4 layers of nested libraries nobody actually understands down, buried under something else. I don't think pixel density has increased as much as you seem to think it has in the 1x scaling space. I ran some very nice 1600x1200 21" monitors back in the day - ~95 ppi. A 27", 2560x1440 monitor (my preferred native size) is 108 ppi. The 24", 1920x1200, is 94 ppi. I understand the issues with scaling a display, but those are more OS level, and shouldn't impact key-to-screen delays noticeably. It certainly doesn't on more recent Apple hardware, even if you're using some screwball non-integer scaling. But the reality remains, I now have 6GHz of CPU cores, 8GB of RAM, and things are objectively slower than 66MHz with 24MB. That's not progress.
    - genewitch 5y ago
      Part of that is interrupt availability and pre-emption; also see https://danluu.com/input-lag/ https://danluu.com/input-lag/
RcouF1uZ4gsC 5y ago
I think a better explanation of this phenomenon is that most users don’t really really care about performance as long as it is above a certain threshold, and care more about features and cost. Given this as long as your software is efficient “enough” - which is easier to reach as computers get more powerful, you are better off optimizing for developer productivity on the desktop. Now this dynamic is complete different on mobile and server since efficiency directly translates to battery use (mobile) and electricity and hardware costs (server).
Vetch 5y ago
This is known as Wirth's law, which the page links to as well as to the ancient quip "what Andy giveth, Bill taketh away." A less cynical take would shift towards the perspective of Gustafson's law. Modern systems attend to more stuff and have more capabilities and affordancies than older trimmer but also simpler software. On Jevon's paradox, a countervailing force is ephemeralization or dematerialization, of which a large aspect is pushing away from resource intensive builds to more energy and information processing intense arrangements.
- Jensson 5y ago
  New developers optimizes time to get a well paying job, so technologies that are quick to learn are optimal. Companies optimizes for worker replaceability, so technologies with lots of fresh candidates constantly being available is optimal. Those two aren't the only thing those groups optimizes for, but they are two of the main things. Which is why we have software bloat, neither group cares that much about user experience.
taneq 5y ago
Desktop software only gets optimized if it's annoyingly slow on the developer's machine. That's why contrary to popular opinion, devs should NOT be testing (only) on the latest greatest machines. It's far to easy to not notice your accidental quadratic or even exponential runtime performance on a lightning fast machine.
Joker_vD 5y ago
It's a really old observation, Joel on Software did it too: "you could spend 6 months carefully optimizing your application, or you could spend this time playing in an amateur rock band, the end result would be the same: 6 months later, your application will run significantly faster".

awb 5y ago

> When you improve the efficiency of the hardware, software starts to demand more CPU cycles, since there's less of an incentive to optimize. Or rather, there’s always more work to be done.

gus_massa 5y ago
For example the orthographic and grammatical correction. When I was young, the browser didn't have it. Now it fix most of my post in HN.
- awb 5y ago
  *fixes
- deleted 5y ago
  [deleted]

Syonyk 5y ago

> ...software starts to demand more CPU cycles, since there's less of an incentive to optimize. Node and Electron and crew would agree. A "modern" chat client (Element, Signal, etc) will lag on a quad core 1.5GHz system in terms of "typing into the text input box" (RasPi4, yes, I've set the governor to performance), when a single core 66MHz 486 could manage that trick without any lag in a range of chat clients. Hexchat still works fine, at least. What we need to do is stop letting developers use high end, modern systems, and put them on something a decade old for daily use. Then maybe they'll stop writing crap that only works well on a 1-2 year old Xeon workstation. Google, I'm looking at you. Buy all your devs a Pi4 and make them use it once a week for a day.

api 5y ago
Some of it is explained by bloat but some of it is explained by things like 4K-5K displays, pretty antialiased fonts, support for multiple languages and unicode, support for inline images and videos, emojis, support for all kinds of inline objects like polls or HTML documents, transport encryption everywhere (sometimes multiple layers of it like Signal ratchet over TLS), scrollback history with search going back to the beginning of time, real time sync between devices, and so on. High resolution displays for example impose an exponential cost right out of the gate. Just printing "hello world" requires more pixels as a function of the square of the increase in resolution. That's more memory, more memory bus traffic, larger bitmaps, scalable vector graphics formats that take more processing power to draw, antialiasing, ... Again I am not writing off bloat. We could probably shrink most software by at least 2X and most Electron stuff by 3-4X. I doubt we could shrink it 10-100X though without sacrificing some of the things I listed up there, especially all the eye candy and rich interaction media.
- Syonyk 5y ago
  In my particular context, it's a Raspberry Pi on a 1920x1200 display, 1:1 pixel scaling, no antialising I know of, and... the rest shouldn't matter that much in terms of how long it takes a key pressed at the keyboard to show up in the input text area. If it does, something is quite wrong in the architecture, IMO, and it's probably 4 layers of nested libraries nobody actually understands down, buried under something else. I don't think pixel density has increased as much as you seem to think it has in the 1x scaling space. I ran some very nice 1600x1200 21" monitors back in the day - ~95 ppi. A 27", 2560x1440 monitor (my preferred native size) is 108 ppi. The 24", 1920x1200, is 94 ppi. I understand the issues with scaling a display, but those are more OS level, and shouldn't impact key-to-screen delays noticeably. It certainly doesn't on more recent Apple hardware, even if you're using some screwball non-integer scaling. But the reality remains, I now have 6GHz of CPU cores, 8GB of RAM, and things are objectively slower than 66MHz with 24MB. That's not progress.
  - genewitch 5y ago
    Part of that is interrupt availability and pre-emption; also see https://danluu.com/input-lag/ https://danluu.com/input-lag/

RcouF1uZ4gsC 5y ago

I think a better explanation of this phenomenon is that most users don’t really really care about performance as long as it is above a certain threshold, and care more about features and cost. Given this as long as your software is efficient “enough” - which is easier to reach as computers get more powerful, you are better off optimizing for developer productivity on the desktop. Now this dynamic is complete different on mobile and server since efficiency directly translates to battery use (mobile) and electricity and hardware costs (server).

Vetch 5y ago

This is known as Wirth's law, which the page links to as well as to the ancient quip "what Andy giveth, Bill taketh away." A less cynical take would shift towards the perspective of Gustafson's law. Modern systems attend to more stuff and have more capabilities and affordancies than older trimmer but also simpler software. On Jevon's paradox, a countervailing force is ephemeralization or dematerialization, of which a large aspect is pushing away from resource intensive builds to more energy and information processing intense arrangements.

Jensson 5y ago
New developers optimizes time to get a well paying job, so technologies that are quick to learn are optimal. Companies optimizes for worker replaceability, so technologies with lots of fresh candidates constantly being available is optimal. Those two aren't the only thing those groups optimizes for, but they are two of the main things. Which is why we have software bloat, neither group cares that much about user experience.

taneq 5y ago

Desktop software only gets optimized if it's annoyingly slow on the developer's machine. That's why contrary to popular opinion, devs should NOT be testing (only) on the latest greatest machines. It's far to easy to not notice your accidental quadratic or even exponential runtime performance on a lightning fast machine.

Joker_vD 5y ago

It's a really old observation, Joel on Software did it too: "you could spend 6 months carefully optimizing your application, or you could spend this time playing in an amateur rock band, the end result would be the same: 6 months later, your application will run significantly faster".