feat: switch memory profiling from peak RSS to live heap usage#22229
Merged
johnathan79717 merged 1 commit intoApr 2, 2026
Conversation
74e32e4 to
8a94083
Compare
8a94083 to
320ae26
Compare
ludamad
approved these changes
Apr 1, 2026
320ae26 to
41bcfeb
Compare
Peak RSS is a monotonically increasing high-water mark that includes freed-but-not-returned pages, making it hard to see when memory is actually freed. Live heap usage via mallinfo2() tracks what's currently allocated by malloc, going up and down as memory is allocated and freed. This matches what Tracy's memory view showed. Now we can see patterns like: alloc 202 MiB -> oink frees to 157 MiB, revealing that commitment batching reclaims ~45 MiB of polynomial memory. Renamed RssCheckpoint to MemoryCheckpoint, rss_mb to heap_mb, add_rss_checkpoint to add_checkpoint.
41bcfeb to
40d6dbc
Compare
e22f2cd
into
claudebox/fix-merge-train-bb-constexpr
7 of 8 checks passed
3 tasks
johnathan79717
added a commit
that referenced
this pull request
Apr 2, 2026
## Summary Replaces #22229 (which was accidentally merged into the wrong branch and reverted). Switches `--memory_profile_out` from peak RSS (getrusage, monotonically increasing) to live heap usage (mallinfo2, goes up and down). This matches what Tracy's memory view showed and reveals when memory is actually freed. - Uses `mallinfo2().uordblks` on Linux, returns 0 on WASM, falls back to peak RSS on other platforms - Renamed `RssCheckpoint` to `MemoryCheckpoint`, `rss_mb` to `heap_mb` - Renamed `add_rss_checkpoint` to `add_checkpoint` Refs: AztecProtocol/barretenberg#1641 ## Example output ``` 0 MultiCallEntrypoint:entrypoint after_alloc 76 MiB 0 MultiCallEntrypoint:entrypoint after_oink 60 MiB <-- freed during commitments 6 EcdsaRAccount:entrypoint after_trace 202 MiB <-- peak 6 EcdsaRAccount:entrypoint after_oink 157 MiB <-- 45 MiB freed 8 SponsoredFPC:sponsor after_alloc 42 MiB <-- small circuit ``` ## Test plan - [x] Builds cleanly (native + asan-fast locally) - [x] Tested with deploy_ecdsar1+sponsored_fpc: heap values go up and down as expected - [ ] CI build passes --------- Co-authored-by: AztecBot <tech@aztec-labs.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Switches
--memory_profile_outfrom peak RSS (getrusage, monotonically increasing) to live heap usage (mallinfo2, goes up and down). This matches what Tracy's memory view showed and reveals when memory is actually freed.mallinfo2().uordblkson Linux (falls back to peak RSS on other platforms)RssCheckpointtoMemoryCheckpoint,rss_mbtoheap_mbpeak_rss_bytes()from logstr for fallbackNow shows patterns like: alloc 202 MiB -> oink frees to 157 MiB, revealing that commitment batching reclaims ~45 MiB.
Refs: AztecProtocol/barretenberg#1641
Example output
Test plan