There is more to do, switches on consecutive numbers are very unlikely, so array solutions don't prove anything, even if the example is so simplistic.
No, switches on consecutive numbers are certainly less common, but not unlikely. The OP describes a situation where the switch is done on the first digit of a string always starting with a digit. The values can only be 0 to 9. I have seen many similar cases where decision have to be taken on the basis of two (or three) specific digits of a telephone number or an IMSI number, or the first byte of an IP address, or the length of words in a phrase, some sequentially ordered items, etc. This is far from uncommon, and there is no reason not to use an array when that occurs.
Arbitrary keys in dispatch tables need hashes.
Yes, and I said on an earlier post in this thread that dispatch tables are usually hashes whose values are coderefs. But if they are not arbitrary values but consecutive numbers, as in the case in point, why not think out of the box and use an array if that is likely to be more efficient (although the difference is only marginal.
Furthermore all my solutions are able to define a "default" case, like given/when does.
Mines return undef, a perfectly admissible default case.
Then goto's allow jumping to multiple lables leading to the same code, for this you need multiple entries in a dispatch hash.
First, I am only very mildly interested about discussing about goto solutions. Second, this has nothing to do with the problem outlined in the OP. Third, the goto solution is not very efficient. Yet, granted, there may be cases where it might simplify the code.
And it should be clear (but mostly ignored/assumed in this thread) that given/when's linear testing of conditions is more flexible then switching to code by literal keys . (C-style I suppose)
Yes, that is absolutely true, but off-topic. The given/when solution is clearly deprecated (well, "highly experimental" is the official expression) at this point.
The latter is an important but limited sub-case, which is ideally optimized under the hood, but measuring both side by side is like comparing apples and oranges.
Not sure to understand what you mean, but, again, I only compared solutions as they were offered by their original posters, nothing more.
You made (rather bold) statements about the execution time of "sub-calls" by benchmarking these arbitrary snippets.
Methinks that I clearly stated that there was a penalty in using dispatch tables. I only said that the penalty was not as large as most people say, especially when the subs are really doing some work. The dispatch table option I used in my benchmark were able to process more than 1.5 million requests per second on my poor laptop.
I made some timings a few months ago on a program that had to split input data between about 8 or 9 output files, based on somewhat complex conditions on the input data. The input data was about 30 million lines and the execution time about 13 minutes. I tried two different approaches: a traditional C-style approach, and a heavily HOP oriented approach (with dispatch tables, function factories, etc.). I did not benchmark them properly, because it would have taken ages, but I timed them several times. The largest execution time difference that I found was, if I remember correctly, 16 seconds, and the average difference about 10 sec. Does that matter? I don't think so when we speak about more than 10 min execution time. One program was 300 lines, the other just 70. Guess which ones?
I hope its evident that "clean" benchmarks are not trival.
Thank you for the lesson, it looks like I did not know, sorry. As I said, I used various people solutions as they were written, including yours. Your goto solution was faster than your hash solution, probably because one used the substr function and the other a regex. These are YOUR solutions as you wrote them, please don't blame me on that.
Having said all that, I'll post soon a new benchmark in which I am trying to make things more comparable. It will shed a different light of this.