Profiling¶
@profile
()¶@profile<expression>
runs your expression while taking periodic backtraces. These are appended to an internal buffer of backtraces.
The methods in Base.Profile
are not exported and need to be called e.g. as Profile.print()
.
clear
()¶Clear any existing backtraces from the internal buffer.
print
([io::IO = STDOUT, ][data::Vector]; format = :tree, C = false, combine = true, cols = tty_cols(), maxdepth = typemax(Int), sortedby = :filefuncline)¶Prints profiling results to
io
(by default,STDOUT
). If you do not supply adata
vector, the internal buffer of accumulated backtraces will be used.format
can be:tree
or:flat
. IfC==true
, backtraces from C and Fortran code are shown.combine==true
merges instruction pointers that correspond to the same line of code.cols
controls the width of the display.maxdepth
can be used to limit the depth of printing in:tree
format, whilesortedby
can be used to control the order in:flat
format (:filefuncline
sorts by the source line, whereas:count
sorts in order of number of collected samples).
print
([io::IO = STDOUT, ]data::Vector, lidict::Dict; kwargs)Prints profiling results to
io
. This variant is used to examine results exported by a previous call toretrieve()
. Supply the vectordata
of backtraces and a dictionarylidict
of line information.See
Profile.print([io],data)
for an explanation of the valid keyword arguments.
init
(; n::Integer, delay::Float64)¶Configure the
delay
between backtraces (measured in seconds), and the numbern
of instruction pointers that may be stored. Each instruction pointer corresponds to a single line of code; backtraces generally consist of a long list of instruction pointers. Default settings can be obtained by calling this function with no arguments, and each can be set independently using keywords or in the order(n,delay)
.
fetch
() → data¶Returns a reference to the internal buffer of backtraces. Note that subsequent operations, like
clear()
, can affectdata
unless you first make a copy. Note that the values indata
have meaning only on this machine in the current session, because it depends on the exact memory addresses used in JIT-compiling. This function is primarily for internal use;retrieve()
may be a better choice for most users.
retrieve
() → data, lidict¶“Exports” profiling results in a portable format, returning the set of all backtraces (
data
) and a dictionary that maps the (session-specific) instruction pointers indata
toLineInfo
values that store the file name, function name, and line number. This function allows you to save profiling results for future analysis.
callers
(funcname[, data, lidict][, filename=<filename>][, linerange=<start:stop>]) → Vector{Tuple{count, linfo}}¶Given a previous profiling run, determine who called a particular function. Supplying the filename (and optionally, range of line numbers over which the function is defined) allows you to disambiguate an overloaded method. The returned value is a vector containing a count of the number of calls and line information about the caller. One can optionally supply backtrace data obtained from
retrieve()
; otherwise, the current internal profile buffer is used.
clear_malloc_data
()¶Clears any stored memory allocation data when running julia with
--track-allocation
. Execute the command(s) you want to test (to force JIT-compilation), then callclear_malloc_data()
. Then execute your command(s) again, quit Julia, and examine the resulting*.mem
files.