Exploratory plot fix

[asmacdo]

Summary

Fixes #399. The current con-duct plot reads totals.pcpu and totals.rss per record and draws a single line for each.
However, both totals double-count (multi-core for pcpu, shared pages for rss), producing the 5363% spike that started this issue.

This PR:

• replaces the summed-totals plot with per-pid traces
• introduces pdcpu, a delta-corrected pcpu computed at plot time from consecutive (etime, pcpu) pairs in usage.jsonl.
• Identity (same physical pid vs kernel pid reuse) is decided by comparing Δetime against Δwall_clock.
• Aggregation-timing artifacts that would otherwise produce negative pdcpu on a continuous pid are clamped to None.
• The default chart filters and caps the legend so the result stays readable on real workloads.

A handful of "REVERT ME" commits with temporary images/data for easier review.

Demo

See tmp-plot-demo.md (BEFORE ps-pcpu drops upper bound)
See tmp-plot-demo.md (CURRENT)

TODO

• Get feedback on approach (Yarik / con-duct maintainers).
  Pre-merge alignment on shape, not just correctness.
• Linux-only math. pdcpu inverts the procps identity
  pcpu = cputime/etime, which assumes ps reports a cumulative
  lifetime ratio. macOS ps reports a 5/8-decayed EWMA, so
  pcpu × etime ≠ cputime and the delta math is meaningless.
  Today's info.json does not record the host platform, so
  we can't tell at plot time whether a log came from Linux. We
  need either:
  - a platform field in info.json (sampler change, separate
  PR), with plot.py refusing or warning on non-Linux logs; or
  - some heuristic (e.g., detect that pcpu monotonically grows
  between two flat-rate samples) and warn.
  Currently silently produces wrong numbers on macOS logs.
• Drop REVERT ME: TEMPORARY DEMO commit (the demo script, demo doc, log files, rendered output)
• Break the memory-humanization binary->decimal in graph into a separate PR

[codecov]

Codecov Report

❌ Patch coverage is 85.71429% with 21 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.96%. Comparing base (2cd8fb9) to head (b748aae).
⚠️ Report is 6 commits behind head on main.

Files with missing lines	Patch %	Lines
src/con_duct/plot.py	81.73%	10 Missing and 11 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #424      +/-   ##
==========================================
- Coverage   91.87%   90.96%   -0.91%     
==========================================
  Files          15       15              
  Lines        1120     1240     +120     
  Branches      139      168      +29     
==========================================
+ Hits         1029     1128      +99     
- Misses         69       78       +9     
- Partials       22       34      +12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[asmacdo]

Main branch renders for reference:

399

fmriprep 1 subject

[asmacdo]

Updated requirements from @yarikoptic review:

• No per-pid color cycling, no cmd labels.
• Per metric (pcpu orange, pmem blue): faint dotted per-pid traces + bold solid "envelope" at max-of-pids per timestamp ("minimum of total use") + dashed "envelope" at sum-of-pids ("maximum of total use" — may be unbounded for now).
• Drop rss from default chart, drop top-N cap. Followup PRs can re-add rss/vsz as opt-in flags.
• 3-entry linestyle legend: solid (max envelope) / dashed (sum envelope) / dotted (per-pid).

[asmacdo]

I think we should consider adding a separate scale 0-100 for pmem on the right side, since pcpu is also percent but can go many times higher for multicore, which effectively squashes pmem. The issue with giving the second axis to pmem is that it would replace rss as the second y-axis.

We could

• add an option to switch between pmem/rss
• add a second plot for rss

wdyt?

[yarikoptic]

previews look much better! what about an alternative I believe I alluded to in the chat -- by default plot rss (not %mem) and state total physical ram in legend (if we know)? Then it would the right "Memory" with abs sizes up and we would be all set -- and I feel that for memory absolute value is good.

[asmacdo]

Swap rss for pmem, done.
Adding host memory to the legend, done. (Note: if the info.json is available, we use it, otherwise we dont include. The demo includes one of each.)

Note: I fixed a bug caused by duplication. The Summary formatter used decimal humanization, the graph used binary but still used MB GB instead of MiB GiB. (Fixed by removing duplication, we now report decimal everywhere). I dont think this bugfix belongs in the PR, but is worth including during draft mode so we can review the plot changes together. I've noted removing this as a TODO in the description.

[yarikoptic]

I slept on it: I think we should make it an explicit option which would allow to switch between plotting "original" pcpu which is a cumulative (and differently across OS as on OSX), vs our "time-point-estimate". So something like --cpu=ps-pcpu,ps-cpu-timepoint so if ps-cpu-timepoint -- we do our conversion estimate and otherwise just plotting original one (no transformation). When plotting, adjust label to become pcpu (time-point) to accent that it is our estimate. The rest stays exactly the same. WDYT?

edit: and in the gallery we will do both plots side -by- side to visualize the divergences.

[asmacdo]

@yarikoptic I agree. That interface seems reasonable. Im trying to imagine how this would play in the future when we may have multiple samplers, (ps regular, ps pdcpu calculated, /proc, psutil, whatever). The info.json could capture the sample type(s), so I think this would play nice with that, and default to the 1 on that was collected or force selection if more than sampling method one was selected.