Benchmarks

Methodology first

The setup

• Clients: nzbfast · SABnzbd 5.0.4 · NZBGet 26.2 · rustnzb 1.3.4 · Weaver, all on the same machine per scenario (Apple M-series boxes: "Europe" M1 Ultra on 10 GbE, "East Coast" M3 Ultra ~2.4–3.0 Gbps line). The provider legs below predate Weaver's inclusion; it appears in the reproducible client-ceiling leg. nzbfast's own figures span builds 1.0.2 to 1.0.8 as the engine changed; older legs understate the shipping build rather than flatter it.
• Fairness: same 6 providers × 8 connections, TLS everywhere, legs run back-to-back interleaved. Every competitor tuned to its documented best: SABnzbd got pipelining_requests=8 (it ships 1, i.e. unpipelined; that setting alone took its 190 GB time from 24m24s to 19m02s), NZBGet got ArticleCache/DirectWrite/DirectUnpack/ParQuick, rustnzb its documented config.
• End state: a verified, extracted, usable file, not "download finished". That's what you actually wait for.
• Reproducibility: every claim is dated and measured the same way: elapsed time + interface byte counters + process-tree peak RSS, 1–2 s resolution. Where a leg runs on a publicly posted NZB, we name it so you can run it yourself.

Scenario 2 · the gap grows with size

Time to usable file, by job size

One-pass means no post-download verify/unpack pass, so the bigger the job, the further ahead it lands. Same-machine sequential runs:

² Their peak footprint (volumes + unpacked output simultaneously, ~156 GB) exceeded the 97 GB free. One-pass needs 1× the content size: it halves the disk you need, not just the time.

Scenario 4 · queue of three

Keeping the line lit across a queue (East Coast, ~43 GB)

Three shapes of the same problem: nzbfast's tail-overlap keeps the line busy edge-to-edge; NZBGet never idles but runs ~35% slower while unpacking concurrently; SABnzbd downloads fast, then leaves the line dark 61% of the time during serial post-processing. In the resilience variant (one job with encrypted RAR headers), SABnzbd's queue wedged on the encrypted job and only 1 of 3 jobs ever completed; nzbfast parked it with a clear message and finished the rest.

Scenario 6 · starve it of RAM

The low-memory ladder: 190 GB in ~1.1 GB of RAM

The same four jobs, re-run at hard memory budgets of 2 GB, 1 GB and 256 MB: what the auto-sizer would pick on an 8 GB box, a 4 GB box, and a 2 GB NAS. Every leg produced a correct, fully verified, extracted file; peak RSS tracked the budget, not the job. Time to usable file, 10 GbE line:

The 20–40% premium on the big jobs is a 10 GbE artifact: spilled blocks only cost time when the line outruns the disk. The same 87 GB job at the same budgets on a ~2.4 Gbps line measured −1% to +7%, noise. On a typical home connection a small budget is close to free at any job size. A NAS profile (2 connections, 256 MB budget) finished the 35 GB job in 0.4 GB peak RSS. A 2 GB NAS can run this. No other client offers a memory ceiling at all.

What a job costs you

Peak disk for a 1.5 GB payload

The one-pass claim is about disk as much as speed, so this is it measured rather than asserted: the highest the working directory ever got during the nested runs, polled twice a second. Reading it once at the end would be meaningless, because a client that deletes its volumes after extracting would look like it never wrote them.

Megabytes, lower is better. NZBGet matches us here and it is worth saying why: it is running with DirectUnpack and DirectWrite on, which is how we configure every competitor, and on these shapes that is enough to reach one copy on disk. SABnzbd holds two. The gap that remains is the one the pipeline was built for: we never materialise the volumes at all, so the peak is the payload itself rather than the payload plus the archive that carried it.

Scenario 8 · five clients, reproducible content

Client ceiling: 9.68 GB served from RAM, and you can rebuild it

Every leg above runs against commercial providers, so you have to take our word for the line conditions. This one you can rebuild yourself: the content is Blender's open movies (Tears of Steel 4K, Sintel, Big Buck Bunny 4K at 60 and 30 fps), CC-BY 3.0, packed store-mode RAR plus 10% PAR2 into 53 files and 14,521 articles, served over loopback NNTP from RAM by a rig in this repository. No provider is involved, so this measures the client itself, with provider variance removed rather than averaged out.

Because the articles come from memory, the absolute times are far shorter than any real download and are not comparable to the provider legs above. Read the ratios and the disk column, not the seconds.

Time to finish runs from starting the job to all four videos being on disk, verified and extracted. Peak disk is the most disk the client ever occupied at any instant, sampled twice a second, and it is the column that matters most here: one-pass needs about 1× the content, everything else about 2×. All five ended holding the same 8.6 GB once they had tidied up, which is exactly why the peak is the interesting figure. Every client produced all four payloads sha256-identical to source. Each is shown at whichever connection count made it fastest (8, 16 and 32 were tried on each; nzbfast was flat at all three, so more connections would not have helped it).

Every competitor at its documented best. A rival must never lose because we misconfigured it, so each client's settings are published with the round. Two are easy to get wrong and worth knowing if you run your own: SABnzbd rewrites its own ini at startup and reverts pipelining_requests to the shipped 1, so pipelining has to be set over the API afterwards and read back to confirm; and a standalone NZBGet -c config inherits NZBGet's built-in defaults rather than the values in its shipped conf, which silently leaves the article cache off. Both ran with those corrected. Weaver is measured warm, because it auto-ramps its connection count and tunes its pools on the first job and its download CLI never exits, so it runs as a persistent daemon with a discarded warm-up pass. Its 8 s is therefore a warmed daemon at 120 connections against our cold one-shot at 8. That is each client at its best by our own rule, but the asymmetry is real and we would rather state it than bury it.

Peak disk is polled twice a second rather than read once at the end, which matters more than it sounds: every client here deletes its volumes after extraction, so all five finish holding the same 8.6 GB and four of them look one-pass if you only measure the aftermath. Polled through the run, four peak near 18 GB. For anything that self-cleans, report the peak, not the leftovers.

Component shootouts

The more technical benchmarks, for people who like more data

Repair (PAR2) and unpack (RAR) are our own native code rather than bundled third-party binaries, so we also race them standalone against the dedicated tools on identical corpora, on three machines spanning what a reader might actually own. A time only counts when the output is byte-identical to the source payload: every RAR figure below was sha256-checked against the source, and every repaired file against the pristine set.

RAR extraction: 8 archive shapes, 6 tools

Each bar is our time as a fraction of unrar 7.23, RARLab's own reference implementation and the fastest of the field on most shapes. Full track = unrar. 32-core desktop, best of 3, tools interleaved inside each round. Seven bars, not eight: RAR4 cannot be created by rar 7.x, so that shape ran on the laptop only and is in the table below.

The whole field, seconds, lower is better. The same archive shapes on all three machines, seven on the desktops and eight on the laptop. Archives were created by official rar 7.23 so no tool is judged on input from its own encoder. rarpar is Weaver's own RAR and PAR2 code, built from source at a5de0d3; we pin the commit rather than a version because its crates carry three different version numbers.

The margins are widest on the laptop, not the 32-core box: small-files 4.4× and solid 2.3× there versus unrar. The parallel decode paths scale into threads that a single-threaded extractor cannot use, so the gap grows on modest hardware rather than shrinking. rars 0.4.7 is the upstream crate we forked, shown unmodified: our fork is 3× to 16× faster than it, which is the extraction work in one column. ² bsdtar has no RAR5 multi-volume support and silently produced a truncated file, so that leg is a correctness failure, not a slow time. ³ rar 7.x can no longer create RAR4, so that one archive comes from the rars encoder (unrar-validated); several tools reject it, and it is the one shape the two desktop rounds could not rebuild, so it appears on the laptop only. ⁴ unar has no Windows CLI, so the laptop field is five tools.

Dates, because they are not all the same. The two desktop groups were re-measured for 1.0.8 on one freshly built corpus, with every tool run from the same staged binaries so no machine raced a different version. The laptop group is the earlier round and is unchanged. That is deliberate rather than lazy: extraction performance did not move between 1.0.7 and 1.0.8, which we checked by racing both builds head to head on every shape and finding them level, so the laptop figures still describe the shipping build. Re-running that rig would have changed the corpus without changing the answer.

PAR2 verify and repair: 1 GiB set, 101 damaged blocks

Corpus: 1 GiB payload packed store-mode into 21 RAR volumes, then a classic PAR2 set at 1 MiB blocks and 10% redundancy, then a fixed 101-block damage map across 6 volumes for the repair leg. Bars are scaled within each machine, since the hardware differs. Lower is better.

Fastest verify and fastest repair on all three machines, against the SIMD par2cmdline-turbo fork, classic par2cmdline 1.2.0 and MultiPar's par2j. Every repaired volume came out byte-identical to the pristine set. The gap is widest on the desktops because our repair path spreads the Reed-Solomon fold across cores; on 14 cores it is 1.4× rather than 2×. Weaver's rarpar was raced on the two desktops as well and lands behind classic par2cmdline on repair: 4.91 s and 5.87 s against our 0.88 s and 1.28 s. ⁵ par2j verifies this set fine but returned a non-zero status on the repair leg in our harness; it likely wants a different invocation and we did not chase it, so read that row as "not measured", not as a failure of MultiPar.

Light damage, the common field case. A handful of failed articles is far more typical than 101 dead blocks, so this round adds a 3-block repair leg: 0.58 s against par2-turbo's 1.12 s on 32 cores, 0.69 s against 1.37 s on 20 cores. It is worth saying what did not move. The 1.0.8 repair rewrite spreads the fold across rows and columns, and rows are the missing-block count, so light damage is exactly where the old code left a big machine idle. In the fold microbenchmark alone that is a 3.65× speedup. End to end it is worth almost nothing, because the fold is about a millisecond of a run dominated by reading and MD5-ing a gigabyte. Both halves are true and the second one is the one that reaches users.

RAR recovery records: repairing without PAR2

When PAR2 cannot cover the damage, the recovery record inside the RAR itself is the last line of defence. Until 1.0.8 ours failed on any archive over about 13 MB, so this leg could not be run at all. Damage is three 3,000-byte holes at 20%, 50% and 80% through the protected region. Both tools produced output byte-identical to the pristine file, and ours is byte-identical to what rar r itself writes.

We lead to about 128 MB and RARLab pulls ahead by 512 MB, so the crossover sits somewhere in the low hundreds of MB. That last row is a loss and it stays on the page: our repair streams rather than holding whole volumes in memory, which costs throughput at the top end and buys a bounded working set. On the 8 GB to 20 GB volumes a daemon actually meets, holding the volume is not an option, so it is the right trade even where it loses. Measured against the buffered path on the same archive: 1.4× slower to run, 2.3× less peak memory.

What else moved in 1.0.8, and where it does not show. Three more engine changes landed that these corpora cannot see, listed here so the numbers above are not read as the whole story: rebuilding a .rev volume now does one erasure solve instead of one per byte; RAR5 archives with tens of thousands of members resolve each member once rather than walking the list per worker (3× less processor time at 40,000 members); and the RAR1.3 bit reader works a word at a time (2×). None of them appear above, because the shapes here have 400 members, no .rev set, and no RAR1.3.

What we deliberately do not do: we never create PAR2. A downloader has no reason to, and ParPar owns that leg. We also buy speed with memory on both engines: extraction peaks around 240 MB against unrar's 41 MB, and verify around 126 MB against turbo's 7 MB, because these are the inline engines that ride a live download rather than standalone one-shots. If you want the smallest possible resident set for a standalone job, the dedicated tools still win that column.

Transport proof

The engine saturates real lines

• 8.31 Gbps aggregate on a measured-8.2 Gbps 10 GbE line (Europe M1 Ultra, 4 providers, 14,000 articles, 0 errors, 0 reconnects).
• 9.16–9.27 Gbps steady transport ticks on the same line, ≈98% of practical TCP goodput.
• 5.44 Gbps sustained through a full 20.4 GB job including in-stream verification.
• Pipelining replicated at every RTT: +64% at 63 ms Starlink, +170–177% at 14 ms datacenter, +270% at 31 ms East Coast. It defeats TCP congestion-window decay, not just latency.
• Backpressure proof: cap the write stage 4× below the network and input locks to the cap ±1% within 2 s, RAM falls, zero swaps. A slow disk can never balloon memory.
• Compute headroom: measured decode+verify ceilings of 86–165 Gbps on Apple silicon. The network is the bottleneck by 4–50× on every machine tested.