Aiui P6 by design, and Rakudo in actuality, pretty much always resolve the dispatch target of a call with multisub candidates at compile-time, not run-time. See my previous comment in this thread for more details.

I accept that, if conditions are favourable to the compiler -- ie. when all the types involved in all the signatures of a multi-sub are of restricted, defined type Int, Str etc. -- and if the compiler will only accept those exact defined types (or their defined subtypes if any) as a signature match; then the compiler will be able to decide which of the multi-subs to call at any given call site, at compile time, by inspecting the types of the arguments at that call site.

But, if a multi-sub set XXX(... ), has its various aliases defined in terms of combinations of Int & str ((say) XXX( int, int ), or XXX( int, Str ) or XXX( Str, Int ) or XXX( Str, Str )); and the user supplies those ints and strings both wrapped over in standard scalars; it is impossible to decide at compile-time which of the set needs to be called, because the only (compile-time) type information at the call site is XXX( scalar, scalar ); which could match any of them.

Thus there are two compile time choices: 1) reject the scalars args at compile time as an unknown sub; 2) generate runtime code to inspect the scalars and decide if the values they contain can be construed as a match for any of the four subs.

Of course any XXX( scalar, scalar ) can match the latter, as any scalar value can be rendered as a string; But equally a scalar string could contain a valid integer. That process of runtime value-typing becomes geometrically more costly in the number of parameter values that need to be inspected.

So, unless library authors writing well-(type)defined APIs are allowed to reject use by lazy, ducktyping, dynamic language enjoying, users; or the compiler is going to come with built-in Psi; multi-subs will have to have a runtime component.

Ie. Before calling one of the 4 type signatures above, it will first have to inspect the values in the parameters and ask "Can this pair of runtime values be construed as a match", for each of the four subs in turn.

And importantly, it will have to consider each of the signatures strictly in the order that the author wrote them in the source; thus denying it another optimisation used by compiled and semi-compiled, strongly typed languages supporting pattern matching.

Does anyone reading this enjoy hacking on an optimizing compiler? :)

Things certainly seem to have come on leaps and bounds in the last year or so, but I would say that you are still at the point of writing "a compiler" rather than an "optimising compiler".

And the types of optimisations you are (still) looking for at this stage are; the right, possibly as-yet-unknown, efficient algorithms to implement some of Perl6's more esoteric features, along with some of those powerful features drawn from languages with strong typing and deep analysing compilers.

Ie. algorithmic optimisation rather than implementation optimisation; and certainly not yet a the stage of peep-holing or JITing. (Which is a good thing relative to some of what went on in the past!)

Maybe MoarVM will be able to stick to the asm.js subset and so gain from the amazing performance that can produce when combined with the latest js engines.

My fears remain that several Perl6 features; and especially certain combinations of those features -- eg. multi-subs taking Junctions and selecting on their runtime states -- leave me with literally no ideas of how you could begin to code them efficiently. Before you can optimise something, you have to have a clear idea of how something works, and some of those combinations simply leave me with a complete vacuum as far as ideas are concerned. And that's despite years of thought and the occasional bit of research.

I still wish the project success. I still have my doubts as to what is achievable.