The fact that C<now> takes longer than C<time> is not
entirely unexpected.  

The C<now> term constructs an C<Instance> object using the
Instance.from-posix method, which represents an opaque
representation of fractional atomic seconds (TAI) in an
epoch-agnostic form.  Since Parrot doesn't provide this
value natively (most systems do not), Rakudo has to construct
the Instance object from the POSIX time value, adjusting it
for leap-seconds and other variations as provided by a table
of leap-seconds.

The C<time> term simply returns the POSIX time value
reported by Parrot's time_n opcode (and doesn't even
have to box it into a PMC), so it's obviously a lot faster.

So there's nothing wrong with C<now>, other than it currently
takes a lot more work to construct than C<time> and we should
probably see about optimizing it.  But the expense of C<now>
serves very much to further the point of the demonstration:
Even in loops where there's a non-trivial amount of work taking
place in the body of the loop, Parrot's GC has the impact of making
some iterations take 10x longer than the rest.

Most of Rakudo's users are less concerned with the time needed
to build Rakudo (which they do rarely) than with the time needed
to compile and run small application programs, which they do
frequently.  This is especially true for people who download
precompiled Rakudo packages and never experience the build time.
I fully grant that your comment can apply also to the time
needed to compile an application program... but as yet most
application programs are far smaller than Rakudo itself, and runtime
speed is often the dominant component there.

I totally understand the reasons why Parrot has not made progress
on GC, and why it's not likely to happen in 2011.  I was asked to
provide a list of current Rakudo needs from Parrot, and GC
performance is one that has been on the list for quite some time.
I'm not seeking for explanations or justficiations of why things are
the way they are, I'm informing the Parrot team of Rakudo's current
needs (as I was requested to do by the participants of this
weekend's PDS).

And I again acknowledge that 2010 saw some significant improvements in
Parrot GC.

But I think I should also offer some thoughts from an HLL camp:
"better GC and memory management" is one of the frequently-cited
"likely advantages" people mention in regards to the idea of
migrating Rakudo to platforms other than Parrot.  Whether running
on other platforms will result in an _actual_ advantage in this
area remains to be seen of course, but I think the ongoing
perception of "slow Parrot GC" is definitely having a very negative
impact on opinions of Parrot in the "HLL marketplace".  

Not only this, but Parrot GC has been cited as a core problem at
meetings and Parrot Developer's Summits for many years now -- even
well before the first PDS in 2008.  As a potential user (and indeed
as a Rakudo developer), I think it damages Parrot's image greatly
that it seems continually unable to resolve what is arguably one
of *the* most fundamental and historically important components
of any dynamic language environment.

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