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

[Peter Lobsinger]

On Mon, Mar 14, 2011 at 9:57 PM, James E Keenan <jkeen at verizon.net> wrote:
> Vasily Chekalkin wrote:
>>
>> Hello.
>>
>> On Mon, Mar 14, 2011 at 8:12 AM, Andy Dougherty<doughera at lafayette.edu>
>>  wrote:
>>>
>>> I don't know if this slowdown is expected or significant, but it's
>>> certainly quite noticeable.
>>
>> It's kind of "expected" due "opsc_full_parse" merge. We now
>> semantically parse ops bodies.
>>
>
> Let me ask the obvious devil's advocate question:  Is this another case
> where Parrot's getting "better" entails Parrot's getting slower?

That is absolutely NOT the case here.

The parsing of ops files has become slower. Which results in
compilation of ops files being slower. However, parsing ops files the
same way Parrot does is not something most Parrot programs do as we do
not even expose a supported API to do so.

> 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).

> kid51
>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>