OCaml Memory Profiler — Beta
Report a Problem
This is the first public release of the ocp-memprof tool. Despite our testing and debugging, you may encounter some issues when using it. Please, do not hesitate to contact us at firstname.lastname@example.org to report a problem, it helps us to improve ocp-memprof's reliability and robustness.
A non-exhaussive list of already known issues and limitations is given below:
No 32-bit support: for now, memory profiling is only supported on 64 bits platforms; if you are interested in 32 bit support, please contact us to discuss your motivations.
Only version 4.01.0: for now, we only provide ocp-memprof for OCaml 4.01.0 on Linux 64 bits platforms.
Broken OPAM Packages: some OCaml packages make strong assumptions on OCaml runtime, that are not compatible with how ocp-memprof profiles allocations. For this reason, it is not possible to profile these packages:
- Coq: we provide Coq 8.4.5 in our OPAM repository. Other versions will fail to compile or behave incorrectly.
Public Change Log
- Feb 13, 2015:
Frequently Asked Questions
- 1. What is the cost of the instrumentation for memory profiling ?
- There are three possible costs, caused by the instrumentation of programs for memory profiling:
- Performance Cost: the instrumentation on generated code
is negligible, but the instumentation within the OCaml runtime can
impact performances. In our tests, the total cost ranges from a
slowdown of 5% (for
ocamlc.optfor example) to 15% (for a specific run of
alt-ergo). For most applications, such a slowdown is acceptable, and not noticable by the user. An additional cost is of course perceived when dumping memory to files (i.e. when actively profiling), which depends on the current memory footprint of the application.
- Memory Cost: there is no memory cost, programs will run with exactly the same memory footprint as before.
- Binary Size Increase: a lot of profiling information (identifiers, types) are stored in binaries for profiling, so binaries were observed to be twice bigger. If needed, it would be possible to store the profiling information in a different file, and such a mechanism will be implemented if needed by our customers.
- Performance Cost: the instrumentation on generated code is negligible, but the instumentation within the OCaml runtime can impact performances. In our tests, the total cost ranges from a slowdown of 5% (for
- 2. What is the main difference between the OCaml Memory Profiler and other memory profilers, say for Java for example ?
- The problem of memory-profiling applications is very close for most managed languages. A lot of analysis can be shared, and the OCaml Memory Profiler implements many analysis that are also available in other profilers for other languages, and is going to provide even more such analysis. The main difference, however, is that OCaml is a completely statically typed language, so that almost no typing information is available at runtime: the memory representation is compact and efficient, but memory profiling is harder without any type information. Most of the work behind the OCaml Memory Profiler was to design and implement a way to store typing information (and more) within OCaml data structures without impacting the current compact representation.