Studio: loss chart silently discards the start of long runs (tail-truncation at MAX_LOSS_POINTS)

[Nicolas0315]

Summary

JobDetail.tsx retains at most MAX_LOSS_POINTS = 2000 loss points using next.slice(next.length - MAX_LOSS_POINTS) (~L223-235). That is a sliding window: once a run emits more than 2000 loss frames, the OLDEST points are dropped, so the chart loses the beginning of the loss curve — exactly the region that shows initial convergence and where most of the loss delta lives. The stats and the visual shape of the run change silently mid-training.

Where

• packages/studio-app/src/pages/JobDetail.tsx ~L27 (MAX_LOSS_POINTS), ~L223-235 (the setPoints updater).
• The cap itself is justified (the comment is right that 2000 exceeds visual resolution and bounds re-render cost) — the problem is only which points are kept.

Proposal

Keep the bound, change the eviction: when the cap is reached, compact by bucketed downsampling instead of dropping the head — e.g. stride-doubling (compact to ~cap/2 representatives, keep appending), with bucket representatives chosen so that (a) points carrying the sparse evalLoss series survive preferentially, (b) local min/max survive so spikes stay visible, (c) the first and last points always survive. Output stays sorted by step, so LossChart's binary-search tooltip (~L240-251, the O(log n) hover lookup) is unaffected.

This keeps memory and render cost identical (still ≤ 2000 points) while the chart shows the whole run at progressively coarser resolution — the standard trade for training dashboards.

(A PR implementing this as a pure, unit-tested helper module is ready to follow this issue.)

[Bishalsingh153]

Hi @soleil-colza @k-taro56 @Nicolas0315 thanks for the detailed writeup — I traced through JobDetail.tsx (L27, L223-235) and LossChart.tsx's binary-search tooltip (L240ish) and confirmed the behavior matches exactly what you described: the tail-slice does drop the earliest points once a run exceeds 2000 frames, and the tooltip's binary search only depends on sort-by-step, so it should be unaffected by a downsampling-based fix.

I'd like to pick this up if that's alright — you mentioned a PR implementing the bucketed/stride-doubling approach is ready to follow this issue. Is that still something you plan to submit yourself, or is it open for someone else to take a crack at? Happy to either wait for yours or start on an implementation along the lines you sketched (pure, unit-tested helper module, preserving first/last/eval-loss points and local min/max) if you'd rather hand it off.

[Nicolas0315]

Thanks for tracing this so carefully. I do not have a PR in flight for this, so please feel free to take it.

The helper-and-tests approach you outlined is the right shape. Please preserve the first and last points, evaluation-loss points, and local extrema, and include coverage for long runs plus the existing sorted-by-step tooltip behavior. Thanks!

[Bishalsingh153]

Hi @Nicolas0315, @soleil-colza thanks for letting me wrapping my head around to solve the issue. I have raised PR for this. Please let me know if you liked it.

[Nicolas0315]

@Bishalsingh153 thank you for putting together PR #230 and for the follow-up commit.

I reviewed the current head and submitted a formal change-request review. The ES2022 compatibility issue, eval-loss priority, and paired documentation are improved. The remaining blockers are repeated compaction losing most historical coverage, split same-step loss/eval frames, budget competition between the two series, statistics being computed from the visualization sample, and oscillation aliasing.

Please address the review on #230 and re-request review once CI and CodeQL have been approved and pass.