4 ms·

A former boss: an optimization made at a non-bottleneck is not an optimization.

mholub 1y ago
it's more nuanced: you're still releasing resources - so you might not become faster overall but you can compute more in the same time later if necessity arises (althougth that might be somewhat premature but can be good for library code - so it becomes more applicable in different environments) and there are some rare but tricky scenarios like: hardware is mobile phone: app seem to be bottlenecked on arithmetics according to the profiler, so it feels obvious to start optimization there in reality what happens - hardware has limit on power, so it can't give full power to CPU, GPU and memory all at the same time since app uses too much memory - it has to redirect power there, also memory emits heat, so CPU becomes throttled By optimizing memory, everything runs colder -> CPU gets more power, can run sustained higher frequencies - app becomes faster
- sethammons 1y ago
  And if the app becoming faster doesn't mean anything because the app is waiting for user input the whole time, it was a lot of work for naught. Perhaps restated: If the optimization cannot be felt (ie, impact on the product experience), it is not an optimization worth pursuing.
  - eru 1y ago
    > And if the app becoming faster doesn't mean anything because the app is waiting for user input the whole time, it was a lot of work for naught. Oh, that might still be good for battery life (or power consumption in general).
  - progmetaldev 1y ago
    This one is more dangerous, as there may be backend resources in use that could be optimized, which could drop costs drastically. This may not change anything for your users, but is definitely worth exploring when it comes to getting the most out of your investment.
bluGill 1y ago
Just remember that there can be hundreds of bottlenecks. Your second slowest matters too. And sometimes there are different requirements - the UI needs to respond within 1/10th second (sometimes much faster, sometimes much slower). Users can often live with your main calculation taking 10x longer than the optimized version so long as there is fast feedback that you are working. Eventually they will want the calculations faster too, but taking a minuter off of those is less valuable than a few ms off of your UI feedback.
the_sleaze_ 1y ago
Translation: I'm "The Boss" so it's not a bottleneck unless I say it is.
DangitBobby 1y ago
It's not true, though. Speedups are speedups even if there are still slow parts.
- godelski 1y ago
  His boss is essentially making the same argument as Knuth: Spend your time optimizing what benefits the most from optimization. Or in other words, prioritize, don't optimize blindly. It's a single line phrase, I wouldn't interpret it too literally. Usually you got to be pretty liberal when interpreting those easy to remember lines. It's a lot harder to remember the literally multiple books we could fill when bringing up exceptions.

it's more nuanced: you're still releasing resources - so you might not become faster overall but you can compute more in the same time later if necessity arises (althougth that might be somewhat premature but can be good for library code - so it becomes more applicable in different environments) and there are some rare but tricky scenarios like: hardware is mobile phone: app seem to be bottlenecked on arithmetics according to the profiler, so it feels obvious to start optimization there in reality what happens - hardware has limit on power, so it can't give full power to CPU, GPU and memory all at the same time since app uses too much memory - it has to redirect power there, also memory emits heat, so CPU becomes throttled By optimizing memory, everything runs colder -> CPU gets more power, can run sustained higher frequencies - app becomes faster

sethammons 1y ago
And if the app becoming faster doesn't mean anything because the app is waiting for user input the whole time, it was a lot of work for naught. Perhaps restated: If the optimization cannot be felt (ie, impact on the product experience), it is not an optimization worth pursuing.
- eru 1y ago
  > And if the app becoming faster doesn't mean anything because the app is waiting for user input the whole time, it was a lot of work for naught. Oh, that might still be good for battery life (or power consumption in general).
- progmetaldev 1y ago
  This one is more dangerous, as there may be backend resources in use that could be optimized, which could drop costs drastically. This may not change anything for your users, but is definitely worth exploring when it comes to getting the most out of your investment.

bluGill 1y ago

Just remember that there can be hundreds of bottlenecks. Your second slowest matters too. And sometimes there are different requirements - the UI needs to respond within 1/10th second (sometimes much faster, sometimes much slower). Users can often live with your main calculation taking 10x longer than the optimized version so long as there is fast feedback that you are working. Eventually they will want the calculations faster too, but taking a minuter off of those is less valuable than a few ms off of your UI feedback.

the_sleaze_ 1y ago

Translation: I'm "The Boss" so it's not a bottleneck unless I say it is.

DangitBobby 1y ago

It's not true, though. Speedups are speedups even if there are still slow parts.

godelski 1y ago
His boss is essentially making the same argument as Knuth: Spend your time optimizing what benefits the most from optimization. Or in other words, prioritize, don't optimize blindly. It's a single line phrase, I wouldn't interpret it too literally. Usually you got to be pretty liberal when interpreting those easy to remember lines. It's a lot harder to remember the literally multiple books we could fill when bringing up exceptions.