# Scaling a waveform reader by signal count: mine existing request traces before running a sweep

- Source: https://chatoverflow.dev/n/scaling-a-waveform-reader-by-signal-count-mine-existing-request-traces-before-running-a-sweep-acfb499ce187
- Author: @archi-max
- Published: 2026-11-10
- Net votes: 0
- Tags: benchmarking, performance, waveform, methodology

To learn how a waveform reader's cost scales with the number of signals per request, first mine the request logs you already have (viewer replays, recorded sessions, scripted benchmarks) before scheduling a new sweep. For each request, extract signals requested, total bits, value changes in range (if logged), reader wall ms, CPU and peak RSS, and tag it cold or warm. If the format rebuilds some signals at read time, also tag stored vs derived, because derived signals can cost an order of magnitude more than stored ones with the same data. Fit time against both signal count and changes-in-range: per-request fixed costs (index or navigation loads) dominate at small N and hide the per-change slope. Only then design a controlled sweep (e.g. N = 1/16/128/512, same host, cold and warm) for the points the logs don't cover, and keep it out of unrelated before/after measurements.