4 ms·

Phones are much less powerful than PCs, but they feel comparably fast because most software developers waste exactly as much performance as they can get away wi

by NickM 8y ago

Phones are much less powerful than PCs, but they feel comparably fast because most software developers waste exactly as much performance as they can get away with. The phone app developers are forced to write better, faster code than the PC app developers, just as PC app developers ten years ago were forced to write better code than PC app developers are today.

zwieback 8y ago
So so true. Every time I go back to programming microcontrollers in C I'm amazed at how much can be done with just a little code. We waste so much on fluff. But then, we do enjoy the fluff.
- zaroth 8y ago
  Fluff in theory should equate to productivity. Sometimes we stop just a bit too soon. I’ve found a great rule of thumb is that once you’re code complete on a module, put in an extra 10% of work with the profiler to try to improve performance. Keep doing 10% spurts until the performance improvement of the last spurt is less than 5x. There’s almost always low hanging fruit which will return at least 10x. Sometimes you find multiple places where you get 10x and your code ends up more than 100x faster. And at that point all your unit tests are written and green so the refactoring is pretty quick. Right? ;-)
  - ajuc 8y ago
    It helps to have performance targets. Like 60fps, sub-100ms ui reactions, no stuttering, throughput matters or not, timing attacks are a concern or not. It's often the case that optimizing a special case 10 times increases throughput, but makes the user experience worse (because it starts stuttering), makes the code ugly, and allows for timing attacks. So, in many contexts it's actually bad idea. Half the work in optimization is measuring the correct thing.
Sohcahtoa82 8y ago
> Phones are much less powerful than PCs, but they feel comparably fast I beg to differ. My Droid Turbo is powered by a 2.7 Ghz quad-core CPU, yet often is incredibly slow. If I want to open Waze and enter and address to navigate to, it's often 10-15 seconds from the time I tap the Waze icon on the launcher until the apps is loaded and the on-screen keyboard has presented itself for typing. There are significant stutters when I'm trying to scroll while a web page is loading. Fallout Shelter takes nearly an entire minute to load. Sometimes, plugging in a USB charger causes the phone to basically become a brick for half a minute or more, as if there are tons of apps deferring processing until I'm on external power. Overall, it often doesn't feel any more responsive than my original Droid back in 2010, which was only a 550 Mhz single core.
- AgentOrange1234 8y ago
  There’s a lot to blame — the software bloat, delivery mechanisms, user-hostile decisions that prioritize ads, and all the rest. But clock rate is truly meaningless as a performance measure when the underlying architecures are different...
  - Sohcahtoa82 8y ago
    > software bloat This came up on another thread here from a blog/article titled "software disenfranchisement". I mentioned that I think a lot of it is an unhealthy obsession with writing re-usable code that results in abstractions on top of abstractions piled onto more abstractions to the point where we get the infamous FizzBuzz Enterprise Edition [0] that I'm sure nearly everyone at HN has seen. We also have a problem of people statically linking massive libraries when they only need a small fraction of its code. > user-hostile decisions that prioritize ads Definitely a problem in mobile web browsing. Ridiculous that on a data-limited connection, ad networks still try to push video ads or ridiculous JavaScript code. > But clock rate is truly meaningless as a performance measure when the underlying architecures are different... Definitely true. ARM gets a lot less done per clock tick than x86. But I imagine a lot of the performance differences are done on purpose as a compromise to reduce power consumption, since ARM is so big on mobile platforms. This is entirely speculation on my part, though. [0] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

by NickM 8y ago

zwieback 8y ago

So so true. Every time I go back to programming microcontrollers in C I'm amazed at how much can be done with just a little code. We waste so much on fluff. But then, we do enjoy the fluff.

zaroth 8y ago
Fluff in theory should equate to productivity. Sometimes we stop just a bit too soon. I’ve found a great rule of thumb is that once you’re code complete on a module, put in an extra 10% of work with the profiler to try to improve performance. Keep doing 10% spurts until the performance improvement of the last spurt is less than 5x. There’s almost always low hanging fruit which will return at least 10x. Sometimes you find multiple places where you get 10x and your code ends up more than 100x faster. And at that point all your unit tests are written and green so the refactoring is pretty quick. Right? ;-)
- ajuc 8y ago
  It helps to have performance targets. Like 60fps, sub-100ms ui reactions, no stuttering, throughput matters or not, timing attacks are a concern or not. It's often the case that optimizing a special case 10 times increases throughput, but makes the user experience worse (because it starts stuttering), makes the code ugly, and allows for timing attacks. So, in many contexts it's actually bad idea. Half the work in optimization is measuring the correct thing.

Sohcahtoa82 8y ago

> Phones are much less powerful than PCs, but they feel comparably fast I beg to differ. My Droid Turbo is powered by a 2.7 Ghz quad-core CPU, yet often is incredibly slow. If I want to open Waze and enter and address to navigate to, it's often 10-15 seconds from the time I tap the Waze icon on the launcher until the apps is loaded and the on-screen keyboard has presented itself for typing. There are significant stutters when I'm trying to scroll while a web page is loading. Fallout Shelter takes nearly an entire minute to load. Sometimes, plugging in a USB charger causes the phone to basically become a brick for half a minute or more, as if there are tons of apps deferring processing until I'm on external power. Overall, it often doesn't feel any more responsive than my original Droid back in 2010, which was only a 550 Mhz single core.

AgentOrange1234 8y ago
There’s a lot to blame — the software bloat, delivery mechanisms, user-hostile decisions that prioritize ads, and all the rest. But clock rate is truly meaningless as a performance measure when the underlying architecures are different...
- Sohcahtoa82 8y ago
  > software bloat This came up on another thread here from a blog/article titled "software disenfranchisement". I mentioned that I think a lot of it is an unhealthy obsession with writing re-usable code that results in abstractions on top of abstractions piled onto more abstractions to the point where we get the infamous FizzBuzz Enterprise Edition [0] that I'm sure nearly everyone at HN has seen. We also have a problem of people statically linking massive libraries when they only need a small fraction of its code. > user-hostile decisions that prioritize ads Definitely a problem in mobile web browsing. Ridiculous that on a data-limited connection, ad networks still try to push video ads or ridiculous JavaScript code. > But clock rate is truly meaningless as a performance measure when the underlying architecures are different... Definitely true. ARM gets a lot less done per clock tick than x86. But I imagine a lot of the performance differences are done on purpose as a compromise to reduce power consumption, since ARM is so big on mobile platforms. This is entirely speculation on my part, though. [0] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...