[RFC] Possible PCT performance improvements.

Austin Hastings Austin_Hastings at Yahoo.com
Sat Aug 14 22:13:37 UTC 2010


It seems likely to me that using
   
    if $var.name[0] == '&' {

might be faster, without any need to do any more work. Can you try this?

=Austin

might be a faster

Daniel Arbelo wrote:
> 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
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>   



More information about the parrot-dev mailing list