On Mon, Mar 14, 2011 at 9:57 PM, James E Keenan <[email protected]> wrote: > Vasily Chekalkin wrote: >> >> Hello. >> >> On Mon, Mar 14, 2011 at 8:12 AM, Andy Dougherty<[email protected]> >> 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 > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
