[R] interpreting profiling output

Kasper Daniel Hansen k.hansen at biostat.ku.dk
Tue Jul 27 04:43:54 CEST 2004


Luke Tierney <luke at stat.uiowa.edu> writes:

> On Sun, 25 Jul 2004, Peter Dalgaard wrote:
>
>> Kasper Daniel Hansen <k.hansen at biostat.ku.dk> writes:
>> 
>> > I have some trouble interpreting the output from profiling. I have
>> > read the help pages Rprof, summaryRprof and consult the R extensions
>> > manual, but I still have problems understanding the output.
>> > 
>> > Basically the output consist of self.time and total.time. I have the
>> > understanding that total.time is the time spent in a given function
>> > including any subcalls or child functions or whatever the technical
>> > term for that activity is. In contrasts self.time is the time spent in
>> > the function excluding subcalls.
>> > 
>> > Now, in my understanding basically everything in R is functions. I
>> > would then guess that for almost any function (except the "atomic
>> > ones") the self.time would be very small as it would spend most of its
>> > time calling other functions (again, since almost everything is a
>> > function). So how do R determine when a subfunction is called?
>> ...brutal snippage...
>> > I guess some of the answers would be clear if I had a firm grasp of
>> > the inner workings of R :)
>> 
>> In a word, yes... 
>> 
>> The profiling keeps track of R's *context stack* which is not quite
>> the same as function calls. Essentially, it only counts R functions that
>> are actually written in R, but not .Internal, .Primitive, etc. So
>> "self" counts the amount of time that a function was at the top of the
>> stack. This is done by a periodic poll which dumps out the context
>> stack at regular intervals. Seeing cases where the self percentages
>> don't add to 100% is, I believe, simply due to truncation of the tails
>> -- that is, there is a large number of different functions which each
>> are counted a few times, and these are not shown in the summary output.
>> 
>> [Sorry about the late reply, but I was out of town, and noone seems to
>> have answered this.]
>
> Just one additional clarification: There are two flavors of
> .Primitive, 'builtin' and 'special'.  You can tell which is which
> using typeof().  Builtins are things like arithmetic operations and
> specials include control constructs like `for`.  At present profiling
> does record builtins but not specials.  Recording specials is
> something we would like to do eventually but it requires more changes
> to the call stack (and dealing with more interections with those
> changes) so it hasn't happened yet. .Internal is a special, so no
> .Internal calls are recorded.
>
> luke
>
> -- 
> Luke Tierney
> University of Iowa                  Phone:             319-335-3386
> Department of Statistics and        Fax:               319-335-3017
>    Actuarial Science
> 241 Schaeffer Hall                  email:      luke at stat.uiowa.edu
> Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu

Thanks to both of you for considering my question. I still have some
problems however. Consider the nnet.default function which uses the .C
interface. As 
> typeof(.C)
[1] "builtin"
I would guess - from my current understanding - that the time spent in
the C functions of nn.default are added to its self.time. Now look at
the output

> prof02.out$by.self[1:10,]
                  self.time self.pct total.time total.pct
nnet.default          33.32     11.2    2186.48      92.1

So nnet.default only used 33.3 on its C calls, but 2186 in total
time. From this I would guess that nnet.default - in my case - spends
its majority of time setting up the fit and postprocessing it (as this
is done by R functions which does not add to its self time). The
actual fit (which is done by the C functions) only takes very little
time. 

Looking further down the table I see

                  self.time self.pct total.time total.pct
as.integer            22.28      7.5      30.92       1.3

as.interger is basically a .Internal call - which ought not to be
recorded. But why does it then have such a "high" self.time?

And finally, if a program (such as mine) have a high discrepancy
between self.time and sampling.time, does this imply that the far
majority of time is spent in .Primitives which are of type special?
-- 
Kasper Daniel Hansen, Research Assistant
Department of Biostatistics, University of Copenhagen




More information about the ESS-help mailing list