[RFC] Possible PCT performance improvements.

[Patrick R. Michaud]

On Sun, Aug 15, 2010 at 09:40:32PM -0700, chromatic wrote:
> On Saturday 14 August 2010 at 16:38, Patrick R wrote:
> 
> > If/when the opcode is added, I'll gladly fix up NQP and the regex engine
> > to take advantage of it.  Ideally I'd like something like:
> > 
> >     $I0 = substreq $S0, $S1, $I1
> 
> I added substr_eq_at on the substr_eq_at branch; updates to NQP and the regex 
> engine there (as well as benchmarks) very welcome.

The opcode appears to have cmp-like semantics (returning -1, 0, +1); if so,
the opcode should be called "substr_cmp_at", since "eq" implies "1 if equal,
zero otherwise".

More to the point, the opcode doesn't seem to do exactly what nqp needs.
If nqp wants to determine if the next token of the source string is the
keyword "when", then we'd like to generate:

    $I1 = substr_eq_at src, "when", $I0

and have $I1 be 1 if the string starting at offset $I0 in src begins
with "when", and $I1 is 0 if it's anything else.  Currently in the
branch I'm getting:

    pmichaud at orange:~/parrot/substr_eq_at$ cat x.pir
    .sub 'main' :main
        .local string src
        src = "given xyz { when 1 { ... } }"
      
        $I1 = substr_eq_at src, "if", 12
        say $I1
        $I1 = substr_eq_at src, "when", 12
        say $I1
    .end
    
    pmichaud at orange:~/parrot/substr_eq_at$ ./parrot x.pir
    1
    1

I suspect what the branch is doing is using cmp semantics and
an offset.  If we prefer to return cmp semantics instead of 
eq semantics, that's fine, but then the comparison needs to
be limited to the length of the token argument (i.e., the
second say above needs to be 0 and not 1).

Thanks!

Pm