You seem to think that I was advocating that this thread should have never happened. Trying to optimize such tiny operations (certainly in Perl) is really just a waste of time as far as achieving actual practical performance improvements. Certainly, it can be fun.

I occasionally enjoy Perl "golf". But I really doubt anybody thinks such code is meant to provide examples of how best to get real work done. Have fun, but where is the harm in having the fun while being aware of the practical meaninglessness of the scores being measured? Do you think the original author is going to pick an approach based on much of anything beyond these scores after such an opening sentence (especially when nobody will even hint at how insignificant the scores will end up being in practice)?

Do you object to GotToBTru perhaps learning a little such that they could avoid again jumping to invalid conclusions based on reports from Benchmark?

The context of the original question is missing to judge whether an optimization in this field matters or not.

Not really. That these alternatives will have almost no impact in a full script is easy to predict from evidence already presented: The high iterations/sec of even the slowest version, the fact that something practical is desired, and that this program will be written in Perl. That "messages" are being constructed just adds another nail to the coffin.

You can even tell Benchmark to notify you when it is producing especially pointless numbers. Just set the iteration count to something reasonable like 10_000. If you get told "too few iterations", then the resulting numbers (no matter how high you raise the iteration count) are more fiction than they are useful.

The math of how performance changes of very small operations very quickly become completely insignificant is quite simple (more "arithmetic" than "math"). And I didn't plan to rehash such in this thread.

Sorry to have interrupted your "learning" with stuff I guess you didn't want to learn? :)