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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
