It is a simple fact of life that if you can hard code a lookup table, it will be faster than building it on-the-fly, or choosing one conditionally.

If you need best possible speed--and that is a big if--then the choice to store 10,000 lookup tables is a speed -v- memory trade-off that you might choose to make.

If youreally need absolute best speed, then C or assembler are your only choices. But the surprising thing about Perl--the redeeming feature for all it faults--is that it rarely make you make that choice. Beyond the realms of either highly algorithmically complex; or no-alternative, cpu intensive--Perl's quirks, irregularities and non-orthogonality's are tailored--by experience and practice, over orthodoxy and dogma--to produce best possible results in best possible time.....

with the proviso--and it is a big one--that you are not afraid to consider perfectionism, passe; correctness. contrived; elitism, irrelevant; and practicality paramount. Beyond the rarefied atmospheres of academic and dogmatic perfection, code that works for the common case. today; is far preferable to either perfection tomorrow.

Strive for perfection; but don't exclude a solution today, for perfection tomorrow. Tomorrow rarely (I'm pragmatic; "never" is not a part of my vocabulary :) ever comes.