make it faster!

[meisl]

Oh boy, indeed...

Here's some first ideas in which directions to go, possibly:

• at least: don't make a new lambda on each and every call to find_method
• maybe better use Routine.wrap rather than "manual" wrapping?
• if at all possible don't disable the method cache. This does NOT mean we may not override it but rather that then we'd better callsame and return its result or just nextsame at the end.

See also these two comments referring to perf: https://github.com/jnthn/grammar-debugger/issues/4#issuecomment-54732451 and https://github.com/jnthn/grammar-debugger/issues/4#issuecomment-54736097

Then, since we all know that premature optimization is the root of evil: there should be a well-organized system of assessing the actual perf of things. So, in order to do this properly, it's necessary to separate

• the overhead coming from pure intercepting (be it via Routine.wrap or not)
• from that coming from printing (right now without color is more expensive since colors are first added, only to be stripped off again for that) Hence pr #7 is a prerequisite.

I'm having in mind a benchmark.pl that'll have markdown-like output to be pasted here. There's already some stuff I have near ready; hope to be able to post examples soon.

[meisl]

Another interesting point is whether more static type information actually helps any optimizer downstream.

However, even if current Rakudo and the VM might or might not know how to use it, it remains to be investigated how to actually provide this information for the wrapping code.

So again, the benefit of providing it for the actual wrapping code should be assessed separately from that of providing it for the other method calls that we introduce (onRegexEnter, onRegexExit, ...)