Re: Optimizing PMC-based MMD

chromatic wrote:
> 
> Within the cmp op bodies, we *know* the arity and most of the types of MMD-
> participant arguments at compile time.  We can get the types of PMC 
> participants within the body of the op itself.  Thus we could avoid most of 
> the argument marshalling and counting and analysis if we had a way to perform 
> cached MMD lookup without constructing a CallSignature PMC.  That would clear 
> up a third of the work.

This we should open up to general discussion. The consequence of 
short-cutting like this is that individual PMCs will no longer be able 
to override 'cmp' to do something other than multi-dispatch. At the 
moment, developers still have the option of providing their own quick 
comparison, which gives an even more extreme speedup than this shortcut.

So, question for language developers and other PMC developers, how 
important is the ability to define a 'cmp' vtable function that's called 
when the 'cmp' opcode is invoked? Or, is defining a 'cmp' multi for your 
PMC type enough?

> Another area for optimization is invoking a Sub from a signature PMC; I 
> believe we're throwing away and recalculating valuable information, though we 
> may have to wait for dramatic improvements until we can unify contexts and 
> CallSignature.

Providing a new way of invoking Subs that uses CallSignatures all the 
way down is already planned in the coming series of calling conventions 
refactors.

> The final opportunity for optimization is making the PMC multis defined in 
> PMCs use PCC instead of C calling conventions.  Corresponding multis written 
> in PIR already use PCC, and we want to support that, so we should unify our 
> approach.  That would remove the NCI expense here, though that's probably 
> minor in comparison to the CallSignature PMC expense.

Changing all NCI calls to something more like PCC calls is already 
planned in the coming series of calling conventions refactors. Changing 
the Pmc2c generator to build PCC subs instead of NCI Subs is a quick 
change that could happen now.

The calling conventions refactors are non-critical (some will likely 
land after 1.0), because the interface will stay the same, it's only the 
internals that will change.

Allison