You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Copy file name to clipboardExpand all lines: doc/src/manual/profile.md
+35-25Lines changed: 35 additions & 25 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -65,6 +65,7 @@ One "family" of visualizers is based on [FlameGraphs.jl](https://github.com/timh
65
65
-[StatProfilerHTML.jl](https://github.com/tkluck/StatProfilerHTML.jl) produces HTML and presents some additional summaries, and also integrates well with Jupyter notebooks
-[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.
68
69
69
70
An entirely independent approach to profile visualization is [PProf.jl](https://github.com/vchuravy/PProf.jl), which uses the external `pprof` tool.
70
71
@@ -308,26 +309,6 @@ and specific lines triggering allocation can often be inferred from profiling vi
308
309
collection that these lines incur. However, sometimes it is more efficient to directly measure
309
310
the amount of memory allocated by each line of code.
310
311
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
-
331
312
### GC Logging
332
313
333
314
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
337
318
[`GC.enable_logging(true)`](@ref), which causes Julia to log to stderr every time
0 commit comments