4 ms·
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 arise
by 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 agoAnd 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 agoThis 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.