| 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`. |