[mholub]

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]

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]

> 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]

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.