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