Skip to content

Commit 713a260

Browse files
simonbyrnepull[bot]
authored andcommitted
Rearrange allocation profiling in Julia manual (JuliaLang#48713)
As mentioned in JuliaLang#48070, the allocation profiler now provides better functionality than the `--track-allocation` option. This rearranges the sections in the manual to reflect this, and adds a note to that effect. It also mentions ProfileCanvas.jl, which seems to be better supported than PProf.jl.
1 parent 184eda0 commit 713a260

File tree

1 file changed

+35
-25
lines changed

1 file changed

+35
-25
lines changed

doc/src/manual/profile.md

Lines changed: 35 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -65,6 +65,7 @@ One "family" of visualizers is based on [FlameGraphs.jl](https://github.com/timh
6565
- [StatProfilerHTML.jl](https://github.com/tkluck/StatProfilerHTML.jl) produces HTML and presents some additional summaries, and also integrates well with Jupyter notebooks
6666
- [ProfileSVG.jl](https://github.com/timholy/ProfileSVG.jl) renders SVG
6767
- [PProf.jl](https://github.com/JuliaPerf/PProf.jl) serves a local website for inspecting graphs, flamegraphs and more
68+
- [ProfileCanvas.jl](https://github.com/pfitzseb/ProfileCanvas.jl) is a HTML canvas based profile viewer UI, used by the [Julia VS Code extension](https://www.julia-vscode.org/), but can also generate interactive HTML files.
6869

6970
An entirely independent approach to profile visualization is [PProf.jl](https://github.com/vchuravy/PProf.jl), which uses the external `pprof` tool.
7071

@@ -308,26 +309,6 @@ and specific lines triggering allocation can often be inferred from profiling vi
308309
collection that these lines incur. However, sometimes it is more efficient to directly measure
309310
the amount of memory allocated by each line of code.
310311

311-
### Line-by-Line Allocation Tracking
312-
313-
To measure allocation line-by-line, start Julia with the `--track-allocation=<setting>` command-line
314-
option, for which you can choose `none` (the default, do not measure allocation), `user` (measure
315-
memory allocation everywhere except Julia's core code), or `all` (measure memory allocation at
316-
each line of Julia code). Allocation gets measured for each line of compiled code. When you quit
317-
Julia, the cumulative results are written to text files with `.mem` appended after the file name,
318-
residing in the same directory as the source file. Each line lists the total number of bytes
319-
allocated. The [`Coverage` package](https://github.com/JuliaCI/Coverage.jl) contains some elementary
320-
analysis tools, for example to sort the lines in order of number of bytes allocated.
321-
322-
In interpreting the results, there are a few important details. Under the `user` setting, the
323-
first line of any function directly called from the REPL will exhibit allocation due to events
324-
that happen in the REPL code itself. More significantly, JIT-compilation also adds to allocation
325-
counts, because much of Julia's compiler is written in Julia (and compilation usually requires
326-
memory allocation). The recommended procedure is to force compilation by executing all the commands
327-
you want to analyze, then call [`Profile.clear_malloc_data()`](@ref) to reset all allocation counters.
328-
Finally, execute the desired commands and quit Julia to trigger the generation of the `.mem`
329-
files.
330-
331312
### GC Logging
332313

333314
While [`@time`](@ref) logs high-level stats about memory usage and garbage collection over the course
@@ -337,17 +318,20 @@ and how much garbage it collects each time. This can be enabled with
337318
[`GC.enable_logging(true)`](@ref), which causes Julia to log to stderr every time
338319
a garbage collection happens.
339320

340-
### Allocation Profiler
321+
### [Allocation Profiler](@id allocation-profiler)
322+
323+
!!! compat "Julia 1.8"
324+
This functionality requires at least Julia 1.8.
341325

342326
The allocation profiler records the stack trace, type, and size of each
343327
allocation while it is running. It can be invoked with
344328
[`Profile.Allocs.@profile`](@ref).
345329

346330
This information about the allocations is returned as an array of `Alloc`
347-
objects, wrapped in an `AllocResults` object. The best way to visualize
348-
these is currently with the [PProf.jl](https://github.com/JuliaPerf/PProf.jl)
349-
package, which can visualize the call stacks which are making the most
350-
allocations.
331+
objects, wrapped in an `AllocResults` object. The best way to visualize these is
332+
currently with the [PProf.jl](https://github.com/JuliaPerf/PProf.jl) and
333+
[ProfileCanvas.jl](https://github.com/pfitzseb/ProfileCanvas.jl) packages, which
334+
can visualize the call stacks which are making the most allocations.
351335

352336
The allocation profiler does have significant overhead, so a `sample_rate`
353337
argument can be passed to speed it up by making it skip some allocations.
@@ -364,6 +348,32 @@ Passing `sample_rate=1.0` will make it record everything (which is slow);
364348
You can read more about the missing types and the plan to improve this, here:
365349
[issue #43688](https://github.com/JuliaLang/julia/issues/43688).
366350

351+
#### Line-by-Line Allocation Tracking
352+
353+
An alternative way to measure allocations is to start Julia with the `--track-allocation=<setting>` command-line
354+
option, for which you can choose `none` (the default, do not measure allocation), `user` (measure
355+
memory allocation everywhere except Julia's core code), or `all` (measure memory allocation at
356+
each line of Julia code). Allocation gets measured for each line of compiled code. When you quit
357+
Julia, the cumulative results are written to text files with `.mem` appended after the file name,
358+
residing in the same directory as the source file. Each line lists the total number of bytes
359+
allocated. The [`Coverage` package](https://github.com/JuliaCI/Coverage.jl) contains some elementary
360+
analysis tools, for example to sort the lines in order of number of bytes allocated.
361+
362+
In interpreting the results, there are a few important details. Under the `user` setting, the
363+
first line of any function directly called from the REPL will exhibit allocation due to events
364+
that happen in the REPL code itself. More significantly, JIT-compilation also adds to allocation
365+
counts, because much of Julia's compiler is written in Julia (and compilation usually requires
366+
memory allocation). The recommended procedure is to force compilation by executing all the commands
367+
you want to analyze, then call [`Profile.clear_malloc_data()`](@ref) to reset all allocation counters.
368+
Finally, execute the desired commands and quit Julia to trigger the generation of the `.mem`
369+
files.
370+
371+
!!! note
372+
373+
`--track-allocation` changes code generation to log the allocations, and so the allocations may
374+
be different than what happens without the option. We recommend using the
375+
[allocation profiler](@ref allocation-profiler) instead.
376+
367377
## External Profiling
368378

369379
Currently Julia supports `Intel VTune`, `OProfile` and `perf` as external profiling tools.

0 commit comments

Comments
 (0)