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? ;-)
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.
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.
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/FizzBuzzEnterpris...