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
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: