Also, would you mind commenting how RProfmem is misleading? There are three ways to profile memory use over time in R code. ... All can be misleading, for different reasons. --- http://cran.r-project.org/doc/manuals/R-exts.html#Profiling-R-code-for-memory-use
The other two ways describe why they are misleading. Hadley On Sun, May 15, 2011 at 8:02 AM, Hadley Wickham <had...@rice.edu> wrote: >>> 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/ > -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel