From tlumley at uw.edu  Sun May 15 22:16:22 2011
From: tlumley at uw.edu (Thomas Lumley)
Date: Mon, 16 May 2011 08:16:22 +1200
Subject: [Rd] RProfmem output format
In-Reply-To: <BANLkTike1kM-wN_GYJEH5WVKQHJMdRijMQ@mail.gmail.com>
References: <BANLkTinazNHgW44pYFycun576E6C9U1L=Q@mail.gmail.com>
	<BANLkTim=QW62QLuduMsXuPp+5N-rTMjdjg@mail.gmail.com>
	<BANLkTike1kM-wN_GYJEH5WVKQHJMdRijMQ@mail.gmail.com>
Message-ID: <BANLkTimiLvxHYaV3DT9FVsh+p6nxPoW+5g@mail.gmail.com>

On Mon, May 16, 2011 at 1:02 AM, Hadley Wickham <hadley at rice.edu> wrote:
> 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)?

The garbage collector doesn't move anything, it just swaps pointers in
a linked list.

The lexer, parser, and evaluator all have  to do some work before a
function context is set up for the top-level function, so I assume
that's where it is happening.

> 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.

Yes. It's obviously better to always print a newline, and so clearly
deliberate not to, that I suspect there may have been a good reason.
If I can't work it out (after my grant deadline this week) I will just
assume it's wrong.


   -thomas

-- 
Thomas Lumley
Professor of Biostatistics
University of Auckland



[Rd] RProfmem output format
Thomas Lumley