Rakudo needs from Parrot in 2011

[Patrick R. Michaud]

On Tue, Feb 01, 2011 at 03:11:07PM +0100, Nick Wellnhofer wrote:
> >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.
> [...]
> Another reason for the large pauses in your simple example is the
> overly large GC threshold that Parrot currently uses. We have
> upcoming fixes for that. But programs that really need a large
> amount of memory will still have noticably long pauses. Parrot's GC
> is much like early JVMs in the 90s in that respect.
> [...]
> Small programs shouldn't exhibit those large delays once the dynamic
> threshold branch is merged and the GC parameters are tuned a little.

Okay.  In this case, part of my message is "Here's a (very) small
program that shows the large delays."  

It's entirely possible that this example is small in source but
has a large memory footprint... but I don't think this should
be the case.  However, your earlier message seems to indicate that
it was in fact quite big -- 3MB for the first iteration.  Is there 
a good mechanism in Parrot to reliably measure the memory consuption 
of various parts of a program?  Ideally I'd like to have some way
to know how much memory is being used at any point in a program,
and which which subroutines have been responsible for allocating it.
(Could the profiling runcore or something like it provide this 
sort of information?)  I think this just brings us back to the
#2 need I listed -- better profiling and performance analysis of 
Parrot programs.

Pm