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
package-benchmark makes it very easy to guard against regressions in allocation counts. However, when a regression does occur, it does not offer much in the way of diagnostic tools to work out where the new allocation was added. In principle Instruments or dtrace can be used to determine this, but the output from those tools is tainted somewhat by the package-benchmark harness itself, as those tools don't know what the measurement window was.
A very useful feature would be a flag to record and output aggregated allocation call stacks. If those stacks are also sorted by allocation count (or output in a structured format that is amenable to further automated processing) it will make it a lot easier to quickly compare the allocations from the before/after flow and determine where the new allocations are.
There are some risks here. Care will need to be taken not to heap allocate in the process of walking the call stack, or we'll trigger infinite recursion. We'll also need to consider how much effort we want to put into supporting older Swift releases, or cases where the frame pointer has been omitted. If we choose not to care about the cases where the frame pointer is omitted, walking the stack should be fairly easy.
The text was updated successfully, but these errors were encountered:
Hi @Lukasa , that would be useful, agree - in general I want to avoid going too much into the deeper analytics territory of dtrace/instruments, but this specific issue would be super useful to make easy.
Perhaps the jemalloc sampling could be leveraged here (https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Heap-Profiling) - although this is only sampling (but perhaps it will be useful enough in practice if the output can be compared easily? Need to check into the output. WDYT?
I tried using jemalloc for this already but it sadly doesn't allow to capture a stack trace on each allocation. It rather shows you the heap usage. What we really need is to hook the swift_alloc calls to then capture a back trace on each allocation.
package-benchmark makes it very easy to guard against regressions in allocation counts. However, when a regression does occur, it does not offer much in the way of diagnostic tools to work out where the new allocation was added. In principle Instruments or dtrace can be used to determine this, but the output from those tools is tainted somewhat by the package-benchmark harness itself, as those tools don't know what the measurement window was.
A very useful feature would be a flag to record and output aggregated allocation call stacks. If those stacks are also sorted by allocation count (or output in a structured format that is amenable to further automated processing) it will make it a lot easier to quickly compare the allocations from the before/after flow and determine where the new allocations are.
There are some risks here. Care will need to be taken not to heap allocate in the process of walking the call stack, or we'll trigger infinite recursion. We'll also need to consider how much effort we want to put into supporting older Swift releases, or cases where the frame pointer has been omitted. If we choose not to care about the cases where the frame pointer is omitted, walking the stack should be fairly easy.
The text was updated successfully, but these errors were encountered: