feat(memtrack): support disabling allocator tracking - #469
Conversation
Greptile SummaryAdds configurable allocator tracking alongside expanded RSS accounting.
Confidence Score: 5/5The PR appears safe to merge because no blocking failures remain within the follow-up review scope. No blocking failures remain. Important Files Changed
|
Merging this PR will not alter performance
|
d983261 to
131f8a3
Compare
GuillaumeLagrange
left a comment
There was a problem hiding this comment.
I'm not sure what's really the usecase of this? olgtm but I'm not sure we've discussed
f1dbc8a to
efc66c8
Compare
7e96222 to
bdd0455
Compare
bdd0455 to
e158870
Compare
Add a --track-allocators flag (default on, env CODSPEED_TRACK_ALLOCATORS) to the memtrack track subcommand. When disabled, memtrack skips the allocator uprobe machinery (exec watcher + attach worker) and only emits coarse mmap/munmap/brk events, reducing overhead on allocation-heavy programs. The mmap/munmap/brk syscall tracepoints are now always attached in every memory run. The runner does not add a CLI flag for this: it relies on the CODSPEED_TRACK_ALLOCATORS environment variable being inherited by the memtrack subprocess, keeping the runner decoupled from the installed memtrack version. Standalone memtrack can still use the CLI flag.
e158870 to
bbff5ff
Compare
What
memtrack track --track-allocators(default on, envCODSPEED_TRACK_ALLOCATORS). When disabled, memtrack skips the allocator uprobe machinery and only emits coarsemmap/munmap/brkevents.Why
Allocation-heavy programs (e.g. a Rust build) generate an overwhelming number of
malloc/freeevents, and the per-allocation uprobes slow the target significantly. This trades allocation granularity for lower overhead while still collecting RSS-relevant memory events.How
mmap/munmap/brksyscall tracepoints are now always attached in a memory run.