Rprof(filename = "Rprof.out", append = FALSE, interval = 0.02,
memory.profiling = FALSE, gc.profiling = FALSE,
line.profiling = FALSE, numfiles = 100L, bufsize = 10000L)
NULL
or ""
to disable profiling. Profiling works by writing out the call stack every interval
seconds, to the file specified. Either the summaryRprof
function or the wrapper script
#ifdef windows
Exactly what the time interval measures is subtle: it is time that the
Rprocess is running and executing an Rcommand. It is not however just
CPU time, for if readline()
is waiting for input, that counts
(on Windows, but not on a Unix-alike).
Note that the timing interval cannot be too small, for the time spent
in each profiling step is added to the interval. What is feasible is
machine-dependent, but 10ms seemed as small as advisable on a 1GHz machine.
#endif
#ifdef unix
How time is measured varies by platform: on a Unix-alike it is the CPU
time of the Rprocess, so for example excludes time when Ris waiting
for input or for processes run by system
to return.
Note that the timing interval cannot usefully be too small: once the timer goes off, the information is not recorded until the next timing click (probably in the range 1--10msecs). #endif
Functions will only be recorded in the profile log if they put a
context on the call stack (see sys.calls
). Some
primitive functions do not do so: specifically those which are
of type "special"
(see the line.profiling
is TRUE
, and if the code being executed
was parsed with source references. See parse
for a
discussion of source references. By default the statement locations
are not shown in summaryRprof
, but see that help page
for options to enable the display.
summaryRprof
to analyse the output file.
Rprof()
## some code to be profiled
Rprof(NULL)
## some code NOT to be profiled
Rprof(append = TRUE)
## some code to be profiled
Rprof(NULL)
\dots
## Now post-process the output as described in Details
Run the code above in your browser using DataCamp Workspace