Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature wish: ocamlprof measures allocation rate #5047

Closed
vicuna opened this issue May 9, 2010 · 1 comment
Closed

feature wish: ocamlprof measures allocation rate #5047

vicuna opened this issue May 9, 2010 · 1 comment

Comments

@vicuna
Copy link

vicuna commented May 9, 2010

Original bug ID: 5047
Reporter: gerd
Status: closed (set by @mshinwell on 2016-12-07T13:46:22Z)
Resolution: won't fix
Priority: normal
Severity: feature
Version: 3.11.2
Category: ~DO NOT USE (was: OCaml general)
Monitored by: mfp @ygrek @Chris00

Bug description

One of the more difficult parts in optimizing ocaml programs is the behavior of the garbage collector. Generally, allocating values is cheap, and freeing memory is expensive. The difficulty is that the consumption of CPU time for GC is delayed, and it is hard to connect it with the part of the program causing it. At least, time-based profilers cannot do it. (In gprof, one often only sees that GC-related functions are at the top of the flat profile, but it is impossible to get a clue why they consume time.)

The suggestion is that ocamlprof is extended so it can also count the number of allocations per function (both local and accumulated, i.e. with called functions). Under the assumption that the GC speed depends mainly on the number of blocks this can give an insight where in the program a lot of blocks are allocated, and it opens the strategy to optimize programs by avoiding allocations.

Additional information

In the past I had good success with this strategy, especially when the program has to deal mainly with small blocks. There are often easy ways to reduce the allocation rate if one only knew which blocks are allocated frequently, e.g. by making block sharing more likely. The optimizations are worth it even if most of such avoided allocations would be collected by the minor collector. It just means that the overall speed of the GC is reduced.

@vicuna
Copy link
Author

vicuna commented Dec 7, 2016

Comment author: @mshinwell

Spacetime will solve all your memory problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant