On 01/02/2011 17:12, Patrick R. Michaud wrote:
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.
Your example does allocate a lot of memory, but it's used only
temporarily, so it shouldn't cause long delays with a dynamic GC
threshold. I'll give it try with the dynamic threshold branch later and
report back.
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,
You can get that number with
interpinfo .INTERPINFO_TOTAL_MEM_ALLOC
It's not really accurate in master, but I plan to add better statistics.
and which which subroutines have been responsible for allocating it.
That's a lot harder.
(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.
Yes, this should probably be part of the profiling runcore. I couldn't
find a profiling task list on the Parrot Wiki. We should create one.
I also found this Wiki page (created 15 months ago):
http://trac.parrot.org/parrot/wiki/RakudoTasklist
We should update this page and link to it from the Wiki front page.
Nick
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
