Of course it's optimized. Like you would expect from a language where the only way to loop is recursion.

Sorry. My point was the mentions of "compiler". Whilst not an all-the-way-to-native-code compiler; it is substantially more optimising than Perl's interpreter.

And the fact that it has a strong type system -- as you pointed out -- means that it has far more opportunities for optimising pattern matching than Perl6 ever will have.

With the basic scalar argument being able to contain anything from undef through integers, floats and strings; to array & and hash references; P6 will pretty much always need to inspect every parameter to a function call at runtime in order to determine which multi-sub to invoke.

And there'll be little, if any, opportunity for the interpreter to change (pre-reorder; for performance reasons) the order in which the multi-subs are considered when attempting the runtime match.

I did a lot of playing with Q for a while. A very nice fully dynamic, compiled to bytecode then interpreted, FPL; but boy was it ever slow.

So slow that it had to be replaced by Pure in which "programs run much faster as they are JIT-compiled to native code on the fly".

My overall point is that adding the syntactic convenience of multi-subs to P6 -- which will probably never be able to benefit from such optimisations -- is another nail in its coffin for programming where performance is important.