Parrot 2.9.1 Released

[Andrew Whitworth]

This thread does raise a few important questions. Most notably, why is
Parrot eating up so much memory? At least, it does appear to be eating
more memory than it had been in months past.

Total amount of memory used by Parrot is really proportional to the
number of strings and PMCs that we have in the system. Other users of
memory, such as global structures (interpreter, etc), method caches,
vtables, and the C stack really don't grow as quickly as the number of
PMCs and STRINGs grow. So the question is whether we have more GCables
alive at any given time, or whether the cost of each GCable has
increased. I think that the size of the PMC header has actually
decreased by at least one pointer size since 1.0. I also don't think
the GC algorithm has changed in any kind of way that would have added
additional overhead to each GCable header since then.

We certainly have changed the way strings work, so I wouldn't be
surprised if we were less aggressive now about freeing up unused
string memory. We may also be more conservative in some places about
keeping PMCs alive longer than they need to be. I can't think of
anything else off the top of my head that would lead us to have
progressively worse memory numbers for completing similar tasks. Does
anybody else know what is going on here, or have any good ideas?

--Andrew Whitworth



On Wed, Oct 20, 2010 at 8:29 AM, James E Keenan <jkeen at verizon.net> wrote:
> Christoph Otto wrote:
>
>> Parrot 2.9.1 News:
>> - This is a bugfix release to address a excessive slowdown in the Rakudo
>> Perl 6 build. If you run out of memory on a box with < 512 MB physical
>> RAM, please report it to us.
>>
>>
>
> With the reversion undertaken in 2.9.1, the burden of "unbearable slowness"
> in build times for Parrot and Rakudo have been taken off the shoulders of
> Rakudo and placed back on those of the users of smaller resource boxes.
>
> On my machine with 256MM phys mem, I recorded these times:
>
> 'make' took          28:54
> 'make smoke' took 2:08::51
>
> So (to use a distinction employed by chromatic in #parrotsketch yesterday),
> this reversion did not "break" Parrot in the sense of causing an error which
> prevented build or run, but it did make it so slow as to render development
> on this machine unfeasible.
>
> Thank you very much.
> kid51
>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>