Commit | Line | Data |
---|---|---|
7f918cf1 CE |
1 | ProfilingAllocation |
2 | =================== | |
3 | ||
4 | With MLton and `mlprof`, you can <:Profiling:profile> your program to | |
5 | find out how many bytes each function allocates. To do so, compile | |
6 | your program with `-profile alloc`. For example, suppose that | |
7 | `list-rev.sml` is the following. | |
8 | ||
9 | [source,sml] | |
10 | ---- | |
11 | sys::[./bin/InclGitFile.py mlton master doc/examples/profiling/list-rev.sml] | |
12 | ---- | |
13 | ||
14 | Compile and run `list-rev` as follows. | |
15 | ---- | |
16 | % mlton -profile alloc list-rev.sml | |
17 | % ./list-rev | |
18 | % mlprof -show-line true list-rev mlmon.out | |
19 | 6,030,136 bytes allocated (108,336 bytes by GC) | |
20 | function cur | |
21 | ----------------------- ----- | |
22 | append list-rev.sml: 1 97.6% | |
23 | <gc> 1.8% | |
24 | <main> 0.4% | |
25 | rev list-rev.sml: 6 0.2% | |
26 | ---- | |
27 | ||
28 | The data shows that most of the allocation is done by the `append` | |
29 | function defined on line 1 of `list-rev.sml`. The table also shows | |
30 | how special functions like `gc` and `main` are handled: they are | |
31 | printed with surrounding brackets. C functions are displayed | |
32 | similarly. In this example, the allocation done by the garbage | |
33 | collector is due to stack growth, which is usually the case. | |
34 | ||
35 | The run-time performance impact of allocation profiling is noticeable, | |
36 | because it inserts additional C calls for object allocation. | |
37 | ||
38 | Compile with `-profile alloc -profile-branch true` to find out how | |
39 | much allocation is done in each branch of a function; see | |
40 | <:ProfilingCounts:> for more details on `-profile-branch`. |