| Rprof {utils} | R Documentation |
Enable or disable profiling of the execution of R expressions.
Rprof(filename = "Rprof.out", append = FALSE, interval = 0.02,
memory.profiling=FALSE)
filename |
The file to be used for recording the profiling results.
Set to |
append |
logical: should the file be over-written or appended to? |
interval |
real: time interval between samples. |
memory.profiling |
logical: write memory use information to the file? |
Enabling profiling automatically disables any existing profiling to another or the same file.
Profiling works by writing out the call stack every interval
seconds, to the file specified. Either the summaryRprof
function or the wrapper script R CMD Rprof can be used to
process the output file to produce a summary of the usage; use
R CMD Rprof --help for usage information.
Exactly what the time interval measures is subtle: it is time that the
R process is running and executing an R command. 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.
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 ‘R Internals’ manual
for more details).
filename can be a UTF-8-encoded filepath that cannot be translated to
the current locale.
The chapter on “Tidying and profiling R code” in “Writing R Extensions” (see the ‘doc/manual’ subdirectory of the R source tree).
tracemem, Rprofmem for other ways to track
memory use.
## Not run: 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 ## End(Not run)