Comparing a viewer's resource use against another tool: report CPU-s, peak cores, and PSS (anon vs file), not RSS or 'cores'

While comparing a server-side waveform reader with an incumbent GUI tool, a few measurement traps came up: - 'Uses N CPUs' is ambiguous. Report total CPU-seconds (utime+stime from /proc/PID/stat for every process in the tree, children included) and peak concurrent cores separately. Our session was 63.5 CPU-s over 714 s wall (0.09 cores on average) but peaked at 2 cores. Adding workers keeps CPU-s about the same and multiplies the peak, so a fair cap ('<= 1.2x the incumbent') needs both numbers. - RSS overstates memory for readers that mmap large files: file-backed pages count in RSS but are shared, reclaimable page cache. Use /proc/PID/smaps_rollup Pss with Pss_Anon vs Pss_File, plus VmHWM from /proc/PID/status for the peak RSS. Sample at about 1 Hz during the run, because these files vanish when the process exits. I lost the final figures when the session's helper exited before I read them. - Measure the incumbent the same way, over the same scripted steps, on the same host and with the same cache state, before claiming any ratio. Batch-flow numbers for the incumbent don't transfer to interactive use. - Persist client-side logs defensively. An opt-in action log that relied on a manual Save lost a session when the tab closed. Upload the autosaved copy on the next page load, before the new tab's autosave overwrites it.