OneMedia subtitle speed rows, version 0.5 (x64)

One publishable run under the exclusive bench queue (wq run --class bench, one filtered group, subsbench 20000 100000, 30 samples), driven by tools/bench/subsbench-run.sh, on main 0794678 plus the ASS tuning commit described below. A first run before that change is described in the notes. Method: docs/bench.md.

Against the bar

Bar: geometric mean of the ratios <= 1.00x and no row worse than 1.25x, against the fastest managed comparator per row (ratio = OneMedia's median over that comparator's median).

Notes

• Rows are parse srt|vtt|ass|ttml and convert srt->vtt|ass|ttml at 20,000 and 100,000 cues, on the synthetic input and with the work described in docs/bench.md. The bar uses the fastest managed comparator per row, which is the Subtitle Edit core library wherever it has the format (SubtitlesParser has no TTML parser and no writers, and is the slowest on every row it has; its ASS reader returns 23,411 of the 100,000 cues).
• OneMedia does more work than the comparators on every row (encoding and line-ending detection, styled spans, extras, defects with offsets, a loss report on conversion), which favours them.
• The rows nearest the limit are parse srt (both sizes) and parse ass at 100,000 cues, where the median sits far above the minimum. At 100,000 cues a run allocates 54 to 110 MB (about 17 MB of it the decoded text) and the garbage collector's share is large; the median swings with the collector while the minimum does not (OneMedia's minimum is below the comparator's minimum on both ASS rows; on the SRT rows it is 1.1 to 1.2 times above). Median is the published figure.
• One indicative tuning pass followed a first publishable run (job 1 of 2, same machine, same method, before the change) that had parse ass at 100,000 cues at 1.44× (median 78.67 ms against 54.65 ms) and parse srt at 100,000 cues at 1.20×, geomean 0.49×. The pass built the ASS override-tag buffer and its two delegates once per cue instead of once per override block (1.5 MB less allocation per 100,000-cue parse); output is unchanged (subsdump: 0 differences over 18,750 input/format lines of the testdata sidecars and 120 damaged variants of each; the subtitle tests pass). The second run, the one tabulated here, has parse ass at 1.21×. The allocation change is 2.4%, so most of that movement is run-to-run collector variance, not the change: treat the row as at the limit, not as comfortably inside it.
• The load average before the run (5.33) is the one-minute average still decaying from the previous job; the machine ran nothing else during it (the exclusive queue).

Run

• Machine: AMD Ryzen 9 7950X3D 16-Core Processor; 32 logical cores; Linux 7.0.0-38-generic x86_64
• ISA: sse4.2 avx2 bmi2 avx512f avx512bw; the input is generated in memory, so storage is not in play
• .NET: 10.0.13 runtime, SDK 10.0.402
• Start 2026-11-02T14:09Z; elapsed 225 s; load average (1 min): before 5.33; during mean 2.36, max 5.33 over 45 samples (5 s samples); after 1.37
• Comparators as restored: SubtitlesParser 1.5.1 (MIT), Subtitle Edit core library 5.3.0 (libse, GPL, public API only, bench project only)
• 30 warm-up runs per implementation, then 30 samples in turn; median and minimum; one process; the bytes are in memory

Rows

Ratio is OneMedia's median over the fastest managed comparator's median. Alloc is bytes allocated per run by the calling thread. Result is what each run produced (cues parsed, or bytes written); SubtitlesParser's ASS reader returns 23,411 of 100,000 cues, so it is not the comparator there when it is slower anyway, and its row is information.