From hadley at rice.edu  Sun May 15 15:02:56 2011
From: hadley at rice.edu (Hadley Wickham)
Date: Sun, 15 May 2011 08:02:56 -0500
Subject: [Rd] RProfmem output format
In-Reply-To: <BANLkTim=QW62QLuduMsXuPp+5N-rTMjdjg@mail.gmail.com>
References: <BANLkTinazNHgW44pYFycun576E6C9U1L=Q@mail.gmail.com>
	<BANLkTim=QW62QLuduMsXuPp+5N-rTMjdjg@mail.gmail.com>
Message-ID: <BANLkTike1kM-wN_GYJEH5WVKQHJMdRijMQ@mail.gmail.com>

>> In the subsequence lines I'm assuming the structure is bytes allocated : call.
>
> I think the five numbers come from four memory allocations before
> example() is called. ?Looking at the code in src/main/memory.c, it
> prints newline only when the call stack is not empty.

Looking into that example in more detail, here's the distribution of
allocation numbers:

   1    3    4
4621   30    2

(with a threshold of 5k)

So it happens ~30 times in total.

So what causes allocations when the call stack is empty?  Something
internal?  Does the garbage collector trigger allocations (i.e. could
it be caused by moving data to contiguous memory)?

Any ideas what the correct thing to do with these memory allocations?
Ignore them because they're not really related to the function they're
attributed to?  Sum them up?

> I don't see why this is done, and I may well be the person who did it
> (I don't have svn on this computer to check), but it is clearly
> deliberate.

It seems like it would be more consistent to always print a newline,
and then it would obvious those allocations occurred when the call
stack was empty.  This would make parsing the file a little bit
easier.

Hadley

-- 
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/



[Rd] RProfmem output format
Hadley Wickham