This is always a tradeoff.

First, the computering industry is about money at the end. What you need to do as a developper is generate value for customer so you get money (that's an oversimplification but the main point is here).

Developper time cost money. Machine power costs money too. Usually, this second costs is way lower than the first one. So, this is capital to have a readable code and maintenable code, so develloper can spend most of theure time delivering value.

micro-optimisation can, in some case, be important. But they usually involve less readable code, or less extendable code (this is not the case of your linked exemple, but in general, it is). This will cost at some point developper's time. This time beeing more expensive than machine power, this is a waste.

Second, micro-optimisation in a large project can make it harder and harder to maintain/make evolve. The problem with that is that when evolving, some other optimisation may be now impossible to do. With an evolving application, you'll typically ends up with a solution that is slower than what you would have got without doing thoses optimisation.

Third, the optimization is often irrevelant as algorithm complexity will generally overcome any micro-optimisation you could have done if the data set grows. Sadly, as micro-optimisation make your code harder to maintain/evolve, thoses optimisation may be harder to do.

Sometime, the value is in this optimisation (think about latency critical programs, like in video games or aircraft's autopilot). But this has to be demonstrated. Usually, your program spend most of the time in a limited portion of code. Whatever micro-optimisation you do, you'll never get your programs any valuably faster without identifying the bottleneck and work on this part.

Asking your question as you did showed that you didn't benchmarked the problem on an actual program. In this case, you could have do the trick and noticed if it was faster or not. So you where asking that before having any problem. This is where the problem is. You were handling the problem of optimisation the wrong way.

As maintenance and evolution are usually more valuable than micro-optimisation, be sure to have the right interface before doing any. Then if parts of your program are abstract enough for one another, you can micro-opmise one without messing up the whole thing. This require that your interface is running for long enough to be trusted.

This is always a tradeoff.

First, the computer industry is about money at the end. What you need to do as a developer is generate value for customer so you get money (that's an oversimplification but the main point is here).

Developer time costs money. Machine power costs money too. Usually, this second cost is way lower than the first one. So, this is capital to have a readable code and maintainable code, so developer can spend most of their time delivering value.

Micro-optimization can, in some case, be important. But they usually involve less readable code, or less extendable code (this is not the case of your linked example, but in general, it is). This will cost at some point developer's time. This time being more expensive than machine power, this is a waste.

Second, micro-optimization in a large project can make it harder and harder to maintain/evolve. The problem with that is that when evolving, some other optimisation may be now impossible to do. With an evolving application, you'll typically end up with a solution that is slower than what you would have had without doing those optimizations.

Third, the optimization is often irrevelant as algorithm complexity will generally overcome any micro-optimization you could have done if the data set grows. Sadly, as micro-optimization make your code harder to maintain/evolve, thoses optimisation may be harder to do.

Sometime, the value is in this optimization (think about latency critical programs, like in video games or an aircraft's autopilot). But this has to be demonstrated. Usually your program spend most of the time in a limited portion of code. Whatever micro-optimization you do, you'll never get your programs any valuably faster without identifying the bottleneck and work on this part.

Asking your question as you did showed that you didn't benchmark the problem on an actual program. In this case, you could have do the trick and noticed if it was faster or not. So you were asking that before having any problem. This is where the problem is. You were handling the problem of optimization the wrong way.

As maintenance and evolution are usually more valuable than micro-optimization, be sure to have the right interface before doing any. Then if parts of your program are abstract enough for one another, you can micro-optimize one without messing up the whole thing. This requires that your interface is running for long enough to be trusted.