Yeah, given that observing a variable at the Perl level could cause SV upgrades within an opcode, maybe it's better to say the challenges are:

• Polymorphic data structures at the C level; with
• SV upgrades in opcodes; leading to
• Large opcode function sizes

We're not talking about JITting a five line Smalltalk method that's monomorphic across 80% of calls here. It would surprise me if the average opcode didn't expand to a size larger—and quite a few basic blocks more‐than LLVM wants to try to JIT.

Nah, implicit type conversions is something JIT compilers can handle.

You don't need guarantees because you just fall back to the generic solution if the input variables become unusual.

It's the checking that makes it slow right now, so I'm not sure how what you said helps.

What I suggested is very similar to memoization.

Only you don't cache the result of a function based on passed values.

You cache the optimized code based on passed types *

see https://en.m.wikipedia.org/wiki/Just-in-time_compilation

Hence the "slow" checking only happens at call time.

(of course you'll need kind of type of inference deduce implied types inside a sub)

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

*) and global states like bigint