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
scope_stats (#858) profiles ring-buffer (and tensormap) resource peaks at per-scope granularity. This issue tracks extending it with per-task and partial-scope collection granularity, added incrementally so the hot path stays cheap.
Motivation / Use Case
#858 deliberately samples only at scope_begin / scope_end to keep overhead minimal — one bool load when disabled, two pure-value calls per scope when enabled. That answers "which scope drove the peak" but not:
Per-task attribution — within a scope that dispatches many tasks, which task(s) actually pushed ring task-window / heap to the high-water mark.
Partial-scope sampling — intermediate peaks inside a long-running scope, so a single scope record does not flatten a time-varying occupancy profile into one number.
Without these, debugging memory pressure inside a large scope still requires guesswork once scope_stats has narrowed it to a scope.
Proposed API / Behavior
Add an opt-in finer sampling level on top of --enable-scope-stats (e.g. a per-task probe at submit_task and/or periodic in-scope sampling), so the default per-scope mode keeps its current low overhead and the finer mode is paid for only when explicitly enabled.
Emit the extra granularity into the existing scope_stats.jsonl stream (additional record types / fields) rather than a new artifact, to keep the consumer side unified.
Follow-up to #858 / #573.
Summary
scope_stats(#858) profiles ring-buffer (and tensormap) resource peaks at per-scope granularity. This issue tracks extending it with per-task and partial-scope collection granularity, added incrementally so the hot path stays cheap.Motivation / Use Case
#858 deliberately samples only at
scope_begin/scope_endto keep overhead minimal — one bool load when disabled, two pure-value calls per scope when enabled. That answers "which scope drove the peak" but not:Without these, debugging memory pressure inside a large scope still requires guesswork once scope_stats has narrowed it to a scope.
Proposed API / Behavior
--enable-scope-stats(e.g. a per-task probe atsubmit_taskand/or periodic in-scope sampling), so the default per-scope mode keeps its current low overhead and the finer mode is paid for only when explicitly enabled.scope_stats.jsonlstream (additional record types / fields) rather than a new artifact, to keep the consumer side unified.Alternatives Considered
submit_taskcost to every profiled run; Add: scope_stats collector for per-scope queue-fill peaks #858 intentionally avoided this.Additional Context
docs/dfx/scope-stats.md), merged as 22538de.