Skip to content

bench(coding-agent): committed instrument for session-load memory - #903

Merged
santhreal merged 5 commits into
mainfrom
perf/session-memory-bench
Aug 25, 2026
Merged

bench(coding-agent): committed instrument for session-load memory#903
santhreal merged 5 commits into
mainfrom
perf/session-memory-bench

Conversation

@santhreal

Copy link
Copy Markdown
Owner

What

A committed instrument for the question this whole perf series keeps asking: what does a large session actually hold in memory?

packages/coding-agent/bench/session-memory.bench.ts builds a synthetic multi-MB transcript (alternating user/assistant turns with multi-KB text blocks and periodic large tool outputs — the shape real sessions have), loads it through the real SessionManager.open pipeline, and reports per phase:

  • heap after a forced synchronous GC (steady-state retention, not garbage),
  • process high-water RSS (VmHWM from /proc/self/status on Linux),
  • context text volume and load time.

SESSION_MB=80 bun packages/coding-agent/bench/session-memory.bench.ts sizes the synthetic session.

Sample output (docker sandbox, 32 MiB / 13,435 entries)

module baseline          heap     7 MiB   rss    81 MiB
entries loaded (166ms)   heap    44 MiB   rss    202 MiB
context text volume      47.5 MiB (UTF-16)
peak RSS                 202 MiB

Why

Every memory claim in this series (#898's export peak, #899's pinned clones) was measured with an ad-hoc script that no longer exists. This makes session-retention measurement reproducible: any future change to session loading, entry shape, or snapshot retention can be diffed against these numbers with one command, and new investigations start from a map instead of a blank page.

Testing

  • Runs green in the test sandbox at 32 MiB; sized via SESSION_MB.
  • bun run check:ts, bun run check:tools clean.

  • bun check passes
  • Tested locally
  • CHANGELOG updated

Measures heap after forced GC per phase (module baseline, entries
loaded, context volume) plus the process high-water RSS while loading
a synthetic multi-MB session through the real SessionManager pipeline,
so memory claims about session retention have one reproducible
instrument instead of a throwaway script per investigation.
@coderabbitai

coderabbitai Bot commented Aug 24, 2026

Copy link
Copy Markdown

Warning

Review limit reached

Next included review available in 21 minutes.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 2930b70e-4fab-4014-a904-1d989e82d2a3

📥 Commits

Reviewing files that changed from the base of the PR and between 46b89ec and 7727cf5.

📒 Files selected for processing (3)
  • CHANGELOG.md
  • packages/coding-agent/CHANGELOG.md
  • packages/coding-agent/bench/session-memory.bench.ts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

The header named three phases and the script had two. Phase 3 was a character
count over the loaded entries, which measures the transcript, not the pipeline,
and buildSessionContext -- the pass that turns retained entries into the message
array a turn carries -- was never called. It is called now, through
SessionManager.buildSessionContext(), so the phase runs against the live entry
array, leaf and id index rather than a re-derived copy.

Each phase also prints high-water RSS beside heap and current RSS. VmHWM is
monotonic, so the rise between two phases is that phase's transient peak; the
header claimed peaks were reported per phase and one line at the end reported
the whole run.

The synthetic transcript moves from the system temp dir to the repo's gitignored
.scratch root. SESSION_MB=500 is half a gigabyte, and where /tmp is a tmpfs that
is half a gigabyte of RAM charged against the measurement being taken.

Refs #903
@santhreal
santhreal merged commit 20a16f1 into main Aug 25, 2026
40 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant