50% slowdown in t/compilers/opsc/02-parse-all-ops.t ?

Christoph Otto christoph at mksig.org
Tue Mar 15 06:05:38 UTC 2011


On 03/14/2011 09:58 PM, Jonathan "Duke" Leto wrote:
> Howdy,
>
>>> What are the implications of this for, say, Rakudo's startup and execution
>>> times?
>>
>> Rakudo does not make use of this code under normal execution. It might
>> be possible to get ahold of the slowed ops parsing code and call that
>> from a Rakudo program, but that is the only situation in which a
>> Rakudo program would be slowed by these changes (and I'd say they'd be
>> asking for it at that point).
>
> Just trying to clarify:
>
> Is it safe to say that this slowdown is only in the compilation of Parrot,
> and not in the runtime of Parrot or any HLLs?
>
> Duke
>

In short, yes.

Less succinctly, the opsc changes were an internal-only refactor that give us 
the flexibility to generate something other than C from .ops files, in 
addition to continuing to generate C.  The code that ops2c currently 
(post-refactor) generates is functionally identical to what was generated 
before the refactor, so its runtime performance will not change.

Christoph


More information about the parrot-dev mailing list