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
