[RFC] Possible PCT performance improvements.

[Daniel Arbelo]

Fellow parrot developers,
   Yesterday, while doing some profiling work on the unshared_buffers
branch, I noticed an interesting pattern in our PIR and NQP code,
which is exemplified by the following nqp snippet:
unless pir::substr($var.name, 0, 1) eq '&' {
   I've also seen this done in PIR in several places, and after
annotating the substr code I saw that it is called 690237 times while
compiling Rakudo's Actions.pm, out of those 436821 (~63%) are calls
with the 'length' parameter set to 1.
While this particular pattern could easily be optimized by calling
ord() to get the character value and an doing integer compare instead
of a string compare, I feel there's more parrot could do to help here.
   For example, looking a bit further I noticed that all but two of
the substr calls in Rakudo's Actions.pm are of the "Extract a
substring and immediately compare it to a constant" variety, most of
the time immediately discarding the obtained substring. This causes a
considerable amount of very short lived headers to be created, chewing
through our available STRING headers in a hurry.
   Discussing it in #parrot chromatic suggested need something like a
"streq_at" op that answers "Does this string at this position contain
exactly this substring?". Does this sound like something PCT could
use? Is it worth adding to parrot? Is there anything else parrot can
do to make code of this kind less likely to be written in the future?

Daniel