./pyperplan.py -H hff -s bfs ../../benchmarks/ipc2023-learning/testing/sokoban/easy-p16.pddl
Find performance bottlenecks in your data processing jobs with the Sciagraph profiler
The Sciagraph profiler can help you find performance and memory bottlenecks with low overhead, so you can use it in both development and production.
Unlike Fil, it includes performance profiling. Sciagraph's memory profiling uses sampling so it runs faster than Fil, but unlike Fil it can't accurately profile small allocations or run natively on macOS.
Need help, or does something look wrong? Read the documentation, and if that doesn't help please file an issue and I'll try to help.
Need help reducing your data processing application's memory use? Check out tips and tricks here.
The flame graphs shows the callstacks responsible for allocations at peak.
The wider (and the redder) the bar, the more memory was allocated by that function or its callers. If the bar is 100% of width, that's all the allocated memory.
The left-right axis has no meaning! The order of frames is somewhat arbitrary, for example beause multiple calls to the same function may well have been merged into a single callstack. So you can't tell from the graph which allocations happened first. All you're getting is that at peak allocation these time, these stacktraces were responsible for these allocations.
The first graph shows the normal callgraph: if main() calls g() calls f(), let's say, then main() will be at the top. The second graph shows the reverse callgraph, from f() upwards.
Why is the second graph useful? If f() is called from multiple places, in the first graph it will show up multiple times, at the bottom. In the second reversed graph all calls to f() will be merged together.
Fil measures how much memory has been allocated; this is not the same as how much memory the process is actively using, nor is it the same as memory resident in RAM.
See this article for more details.