Benchmarks

Kortversionen · uppmätt 23 augusti 2026 på kodlinjen som levererades som nzbfast 1.2.2

Ingen uppmätt klient är billigare på processor, minne och disk tillsammans

De senaste omgångarna på den här sidan kördes 23 och 24 augusti 2026 - den senaste av dem på själva utgåvebygget v1.2.2 - mot aktuella byggen av fyra andra klienter på identisk hårdvara, linjer och providers: två jobb- former från 6,5 till 87 GB, och linjehastigheter från 250 Mbit till 10 GbE. I de omgångarna var ingen klient billigare än nzbfast på processor, minne och disk tillsammans: var och en kostar mer på minst två av de tre, det mesta någon av dem sparade på någon enskild axel var omkring 2 procent - ett statistiskt oavgjort, inom den klientens egen spridning mellan körningar - och på disk flyttade var och en av dem minst dubbelt så många byte för ett byte-identiskt resultat. Som levererad höll nzbfast också minst minne av alla uppmätta klienter, på varje fixtur, med 2,0x till 4,5x mot den närmaste konkurrenten.

Vilken är du?

De flesta nedladdare skriver din nedladdning till disk minst två gånger: en gång medan den laddas ner, och igen medan den packas upp. nzbfast gör hela jobbet i ett svep, så den skriver omkring hälften av byten per jobb, håller mindre i minnet medan den arbetar, och spenderar färre processorsekunder per GB. Det är mindre belastning på maskinen medan du använder den och halva antalet skrivningar per jobb på dina diskar, för samma byte-identiska filer - och eftersom varje byte korsar disken ungefär en gång behöver din disk bara hänga med din linje en gång.

nzbfast vinner inte varje tabell på den här sidan, och de den förlorar finns under etapperna vi inte vinner - inklusive en från samma omgång. Det som höll i varje omgång vi mätte är den samlade notan.

Metodik först

Upplägget

• Klienter: nzbfast · SABnzbd · NZBGet · rustnzb · Weaver, varje tabell på de byggen den namnger. De senaste omgångarna (23 augusti 2026) körde mot fältets då aktuella byggen - SABnzbd 5.1.1, NZBGet 26.3-testing, rustnzb 1.4.5 och Weaver 0.7.8, dess senaste levererade binär, identiteten bevisad med hash - mot den kodlinje som levererades samma natt som nzbfast 1.2.2, så bygget som gav de nya siffrorna är det du kan ladda ner. De omgångarna kördes på en 20-kärnig Apple Silicon-maskin på en 1 Gbit-linje. Äldre tabeller behåller de byggen och maskiner de kördes mot (Apple M-serien: "Europa" M1 Ultra på 10 GbE, "östkusten" M3 Ultra ~2,4-3,0 Gbps-linje) och säger så; de underskattar det levererade bygget snarare än smickrar det.
• Rättvisa: samma providers och TLS överallt för varje klient, etapperna körda tätt efter varandra och växlande. Varje konkurrent inställd på sitt dokumenterade bästa: SABnzbd fick pipelining_requests=8 (den levereras med 1, alltså opipelinerad, och inställningen är värd tvåsiffriga procent på stora jobb), NZBGet fick ArticleCache/DirectWrite/DirectUnpack/ParQuick, rustnzb sin dokumenterade konfiguration. Sedan 20 augusti 2026 kör varje omgång fem providers snarare än sex - antalet providers är ingen hastighetsspak på de här maskinerna, där en enda provider ensam kan nå linjetaket, och en fast uppsättning håller omgångarna jämförbara - så en sexprovider-siffra på den här sidan är inte direkt jämförbar med en nyare femprovider-siffra, och varje tabell säger vilken den körde.
• Sluttillstånd: en verifierad, uppackad, användbar fil, inte "nedladdningen klar". Det är vad du faktiskt väntar på.
• Reproducerbarhet: varje påstående är daterat och uppmätt på samma sätt: förfluten tid + räknare för nätverksgränssnittets byte + processträdets toppvärde av RSS, 1-2 s upplösning. Där en etapp körs på en publikt postad NZB namnger vi den så att du kan köra den själv.
• Metodanmärkningar som gäller för hela sidan: CPU-tid samplas från process- trädet vid 2 Hz på varje arm i en tabell och placeras aldrig bredvid en siffra från en annan bokföring, eftersom de två metoderna är avsedda att inte stämma överens. Diskens I/O anges i GiB och nätverksbyte i decimala GB; vi konverterar innan vi dividerar. Och varje tabell som ställer vårt eget bygge mot vårt eget bygge har en A/A-kontroll - samma binär körd mot en byte-identisk kopia av sig själv genom samma testverktyg - eftersom den kontrollen är hur vi upptäckte att vårt eget jämförelseverktyg gav en ~1,5% straffavgift till vilket verktyg som helst som körde först (historien nämns bredvid extraktions- tabellerna nedan). Två armar och omkastad ordning tar inte ut en snedvridning som alltid drabbar den första armen; en A/A-kontroll avslöjar den.

Långsammare linjer · uppmätt 24 augusti 2026 på nzbfast 1.2.2

Ju långsammare linjen, desto mindre skiljer hastigheten klienterna åt - och desto mer gör notan

På en tillräckligt långsam linje är varje klients sluttid linjen och inget annat, så en långsam linje döljer många synder. Det den inte kan dölja är vad varje klient förbränner för att fylla den. Vi formade 1 Gbit-riggen till två hastigheter som verkliga planer faktiskt ligger på och körde alla sex armar vid varje - samma maskin, samma fem providers, tre upprepningar per klient med ordningen roterad, varje etapp byte-kontrollerad, 36 av 36 korrekta över de två omgångarna. nzbfast-armen vid 500 Mbit är själva v1.2.2-utgåve- bygget.

Läs de två tabellerna som en gradient. Vid 250 Mbit landar hela fältet inom 18% på klockan och vi leder den närmaste konkurrenten med 4,4%; vid 500 Mbit öppnas gapet till 14,7%; vid gigabit- och 10 GbE-hastigheterna i tabellerna ovan och nedan öppnas det ytterligare. Hastighetsskillnaderna växer med linjen. Resurskolumnerna väntar inte på en snabb linje: vid varje uppmätt hastighet höll varje konkurrent minst 3,9x minnet, spenderade mer processor, och flyttade omkring dubbelt så många diskbyte för samma byte-identiska fil.

Anslutningsregulatorn tjänar in sitt uppehälle på långsamma linjer, och shaperns egen dropp-räknare säger varför. Levererade standardinställningar höll 25 anslutningar där varje konkurrent körde hundratals; samma binär med regulatorn avstängd körde 360. Färre flöden genom en fast kö betyder mindre förlust och mindre ombegäran: shapern registrerade omkring 4 200 tappade paket per begränsad etapp mot omkring 155 000 obegränsade vid 500 Mbit, och den begränsade armen var snabbare, 4,2x lättare på minne och 1,3x lättare på CPU än vår egen hållning med 360 uttag. Fler anslutningar är inte mer hastighet; under en gigabit är det mätbart motsatsen.

Uppmätt 24 augusti 2026, medianer av tre, på en 20-kärnig Apple Silicon-maskin med sin linje formad till varje hastighet (den formade hastigheten verifierad av en oberoende sond före varje omgång: 248 och 496 Mbit). Den 500 Mbit nzbfast-armen är v1.2.2-utgåvans tagg-bygge; 250 Mbit-omgången kördes timmar tidigare på samma kodlinje. Byteantal på en formad linje läses från varje klients egen räknare, aldrig nätverksgränssnittet (shapern tappar paket och TCP skickar om, så gränssnittet räknar båda kopiorna). Klocktider är jämförbara inom varje tabell, inte över olika formade omgångar. ¹ NZBGets tre etapper vid 500 Mbit spände 114-158 s med platta resursavläsningar - en verklig spridning, så medianen anges och spridningen redovisas i stället för att smalnas av.

Den skadade posten · omkörd 24 augusti 2026, alla byggen aktuella

När inlägget har hål i sig: 6,5 GB med 60, 20 och 5 döda artiklar

Artiklar går ut, servrar tappar dem tyst, uppladdningar landar ofullständiga - och skada är där gapet mellan klienter är bredast, så den får sin egen omgång på det senaste bygget av varje klient, nzbfast v1.2.2 inkluderad: Europa 10 GbE-maskin, fem providers, 100 anslutningar per klient, samma 6,5 GB-utgåva förgiftad på tre skadenivåer, tre upprepningar per arm med ordningen alternerad, varje etapp byte-kontrollerad mot den rena filen. 63 av 65 etapper kom tillbaka byte-identiska; de två som inte gjorde det namnges nedan, eftersom de är resultat.

Varför den skadade posten är snabb här. När en artikel saknas frågar en klient normalt nästa server, sedan nästa, tills varje server har nekat den - en seriell vandring vars nekanden tar allt från tiotals millisekunder till ett par sekunder vardera, under vilken nedladdningen står stilla på noll. nzbfast slutar fråga: så snart paritetsdatan som redan finns till hands täcker det som fortfarande saknas, reparerar den omedelbart i stället för att fullfölja vandringen. Det är den andra raden - samma binär med det beteendet avstängt är 1,4x till 2,3x långsammare beroende på skada - och omgången verifierade att mekanismen kopplades in på varje aktiverad etapp och aldrig på en avstängd. Mot den närmaste konkurrenten är marginalen 2,4x till 2,7x, utan överlapp i något av de nio upprepningsparen.

Disk är där marginalen är bredast, och det är inte reparationstricket. Varje slutförande arm gav samma 6,48 GB-fil; vår flyttade 6,2-6,8 GB disk-I/O för att göra det, NZBGet 12,7-18,5 GB, SABnzbd 13,9-20,3 GB och rustnzb 12,8-13,1 GB. Det är enpass-pipelinen - den avstängda raden flyttar samma 6,2 GB - så det håller på både skadade och oskadade inlägg.

¹ SABnzbds tre etapper vid den tyngsta skadan körde 43, 41 och 60 s - en verklig spridning på identiska indata, så medelvärdet anges med intervallet redovisat. ² rustnzb 1.4.5 levererade varje etapp byte-korrekt, och dess kostnad ligger i processortid snarare än tillförlitlighet: omkring 1 620 CPU-sekunder mot en 107 s klocka vid den tyngsta skadan - ungefär femton kärnor upptagna genom hela etappen - där samma reparerade utdata kostar oss omkring 50 CPU-sekunder. ³ Weaver flyttade 1,5 GB och 4,9 GB av de 6,5 inom vår 20-minuters- gräns vid de två tyngre skadenivåerna - samma utebliven klar-markering i alla tre omgångar som har kört mot den, tre separata nätter. Vid 5 döda artiklar blev den klar korrekt alla tre gånger. Dess processorkostnad där är sin egen historia: omkring 2 325 CPU-sekunder för 194 s-etappen, mot våra 20.

Uppmätt 24 augusti 2026, alla byggen aktuella: nzbfast v1.2.2 (själva utgåvetaggen), NZBGet 26.3-testing (bygget från 20 augusti), SABnzbd 5.1.1, rustnzb 1.4.5, Weaver 0.7.8. En kontinuitetsarm körde mot föregående natts nzbfast-bygge inuti samma omgång och landade inom en sekund av v1.2.2 på varje fixtur, så inget här rider på en lyckträff; och konkurrenternas konfigurationer skiljer sig från föregående omgångs enbart i sökväg, kontrollerad nyckel för nyckel innan omgången kördes.

Svält det på RAM · uppmätt 24 augusti 2026 på nzbfast 1.2.2

Lågminnesstegen: 87 GB i ~0,3 GB RAM

Samma 87 GB-jobb som omgången ovan, omkört med hårda minnesbudgetar på 2 GB, 1 GB och 256 MB - vad autoväljaren skulle välja på en 8 GB-maskin, en 4 GB-maskin, och en 2 GB-NAS. Varje etapp gav den identiska byte-kontrollerade filen, och minneskolumnen följde budgeten, aldrig jobbet:

En enda etapp per budget på utgåve- bygget, kontrollerad mot samma checksumma som sexarmsomgången. Den snävaste budgeten kostar omkring 9% av väggtiden, och bara för att den här linjen är 10 GbE - block som spills över kostar tid bara när linjen springer om disken, så på en typisk hem- anslutning är en liten budget nära gratis. Hela stegen, inklusive en 87 GB-nedladdning, ryms i 0,3-0,6 GB minne; vid levererade standardinställningar körde jobbet i 286 MB. Ingen annan klient erbjuder en hård processomfattande minnesbudget; de närmaste sakerna är cache-storleksreglage, och omgången nedan mäter vad de kostar.

Begränsningen körd mot fältets egna reglage. På 34 GB-fixturen (23 augusti 2026, 1 Gbit-maskin, fem providers, 30 av 30 etapper byte-korrekta), fick ett cache-tak likvärdigt med NZBGets att mer än fördubbla dess CPU (215,5 till 453,0 CPU-sekunder, 2,10x) för att köpa en 52% minskning av dess toppminne, och SABnzbds tak var nästan gratis men nådde bara en del av dess fotavtryck. rustnzbs cache-inställning var dekorativ i bygget som kördes, och Weaver har inget minnesreglage alls, så båda kördes obegränsade som referenskolumner snarare än att poängsättas vid en budget de inte kan hålla. Vår egen sida av den omgången är ersatt av v1.2.2-stegen ovan, som säger samma sak vid 2,5x storleken: budgeten är aldrig den bindande begränsningen, eftersom enpass håller så lite från början.

Ledigt utrymme · uppmätt till megabyten

Hur lite ledigt utrymme ett jobb behöver

En skriv-ut-och-packa-upp-klient behöver plats för både arkivvolymerna och den uppackade nyttolasten samtidigt, så ett jobb startar inte utan ungefär dubbla nedladdningen ledigt. Enpass behöver innehållet - och den här omgången mätte hur lite mer, genom att krympa målvolymen tills varje klient misslyckades. nzbfasts svar är en konstant på omkring 50 MB marginal, inte ett förhållande, och det håller från ett 6,5 GB-jobb till ett 34 GB-jobb.

Uppmätt på en 20-kärnig Apple Silicon-maskin, 1 Gbit-linje, fem providers, tre upprepningar vid varje gräns, varje slutförd etapp byte-kontrollerad - konkurrentraderna 22-23 augusti 2026 (Weavers 34 GB-cell omkörd den 24 augusti, not 1), och nzbfast-raden omskuren på v1.2.2-utgåvebygget den 24 augusti, som reproducerade båda gränserna exakt, 12 av 12 etapper eniga över de två fixturerna. Våra celler är ett uppmätt golv: jobbet slutförs 3 av 3 med 48,6 MB och 51,0 MB marginal, och nekas 3 av 3 omkring 17 MB under det - så golvet är verkligt i båda riktningar. Vad jobbet faktiskt håller landar på utdata plus omkring 3 MB; marginalen betalar för pipelinens sista ögonblick, aldrig för en andra kopia. Konkurrenternas celler är deras uppmätta golv på 6,5 GB-jobbet och en bekräftad tillräcklighet vid samma förhållande på 34 GB-jobbet (3 av 3 byte-korrekta vid exakt det förhållandet); vi vandrade inte deras stege längre ner vid den större storleken, så deras verkliga golv där kan ligga något under förhållandet, och vi säger så i stället för att runda till vår egen fördel.

Vad det faktiskt ser ut som att ta slut spelar lika stor roll som siffran. 17 MB under sitt golv träffar nzbfast diskens avvisning vid en skrivning, stannar rent med "out of disk space", behåller allt som landat journalfört, och ett nytt försök återupptas utan att hämta om - en delfil du behåller, inte ett misslyckat jobb. ¹ Weavers cell för den stora fixturen avgjordes av en omkörning den 24 augusti: tre av tre etapper byte-korrekta vid samma ~2,25x, var och en snabbare än den bra etappen från första försöket, på ledigt utrymme identiskt ned till byten. Vid första försöket, den 23 augusti, hade två av dess tre etapper avstannat vid enstaka MB/s med mer än 60 GB fortfarande ledigt och nått omgångens 40-minutersgräns. De avstannandena kom inte tillbaka, och riggens avstanningsmätning var utrullad och tyst på alla tre etapperna i omkörningen, vilket är en positiv mätning och inte en utebliven. Vad som orsakade dem är fortfarande okänt, och en ren omkörning är ingen diagnos: det finns nu sex etapper vid detta förhållande, fyra slutförda, och båda felen kommer från ett enda 80-minutersfönster den första natten.

Nästlade inlägg · mätt den 28 augusti 2026

Tio sätt att paketera ett inlägg, och vem som faktiskt når filen

Mycket av det som publiceras är avsiktligt svårt att öppna. Det riktiga filnamnet ligger begravt i ett andra arkiv, ibland ett tredje, ibland i ett annat format på varje nivå, så att inlägget avslöjar så lite som möjligt om vad det innehåller. Till det kommer att inlägg anländer skadade: artiklar löper ut, uppladdningar landar ofullständiga och återställningsdatan måste användas innan något alls kan packas upp. En klient går igenom den kedjan åt dig, eller så räcker den över en mapp med arkiv och stannar.

Vi byggde därför tio former som isolerar just detta, lät varje aktuell klient möta dem och gjorde sedan det som jämförelser brukar hoppa över: där en klient slutade i förtid avslutade vi jobbet för hand med standardverktygen och tog tid på det också. En klient som ger upp snabbt ser snabb ut tills man räknar det arbete den lämnar kvar till dig.

nzbfast är den enda som klarar alla tio utan hjälp. NZBGet når också filen i varje form, men behöver 16 omgångar av manuell reparation och uppackning i åtta av dem. SABnzbd klarar fem på egen hand och två är oåtkomliga även för hand. Weaver når filen i två.

Mönstret är inte slumpmässigt. De former som nzbfast tar sig igenom och de andra inte är de paketerade och de skadade: ett arkiv i ett arkiv, ett formatbyte halvvägs ned, en kedja i fem nivåer och framför allt ett arkiv som anländer trasigt med sin egen återställningsdata bredvid. På den sista packar fyra klienter upp den yttre uppsättningen felfritt, räcker över det trasiga arkivet tillsammans med den återställningsuppsättning som skulle laga det, och stannar.

Där klienterna gör samma arbete är skillnaden stor. Detta är de sju former som alla fyra vanliga klienter når, inklusive den manuella reparation var och en behövde:

Fyra till fem gånger snabbare, på mindre än hälften av de skrivna byten. Disksiffran är den som fortsätter spela roll efter nedladdningen: varje gigabyte i den kolumnen är en gigabyte som din disk har fått ta emot, och de klienter som mellanlagrar jobbet skriver ut innehållet, läser tillbaka det och skriver det igen.

Där vi inte ligger före, och varför det är värt att säga. På fyra av de tio formerna skriver en konkurrent färre byte än nzbfast under själva nedladdningen. Varje gång beror det på att den gjorde mindre: på formen med skadat innerarkiv skriver NZBGet 3,29 GB mot våra 4,65, och sedan skriver dess reparationsomgång ytterligare 2,91 och slutar på 6,20 GB mot våra 4,65. På de övriga är den klient som skrev minst en som aldrig nådde filen. En låg disksiffra är inte alltid sparsamhet.

Detta är kapacitetstester, inte hastighetstester. Innehållet är litet och serveras ur minnet över en lokal anslutning, utan leverantör och utan nätverk i vägen, så inget här begränsas av nedladdningshastigheten och de absoluta sekunderna är långt kortare än vad samma former skulle ta i verkligheten. Huruvida en form över huvud taget kräver handpåläggning är en egenskap hos formen och klienten och överförs direkt. Sekunderna jämför klienter som gör identiskt arbete, de förutsäger inte hur lång tid ett verkligt jobb tar.

Fullständiga resultat per form, vad varje form är och metoden finns på datasidan om nästlade arkiv.

Varför det spelar roll

Din disk gör halva jobbet

Flashlagring slits ut av att skrivas till. En 94 GB-utgåva kostar din disk omkring 90 GB skrivning under nzbfast; under en klient som mellanlagrar och packar upp kostar samma utgåva ungefär dubbelt. På en NAS med hårddiskar tar enpass-formen också bort den långa entrådiga passagen i slutet av varje krypterad nedladdning - en paus uppmätt till 20 sekunder på en snabb 32-kärnig arbetsstation med hårdvaruaccelererad upplåsning, och motsvarande längre på de lågeffekts-maskiner de flesta faktiskt kör det på. Vi citerar den lilla siffran eftersom det är den vi mätte.

Komponentdueller

De mer tekniska benchmarkarna, för dig som vill ha mer data

Reparation (PAR2) och uppackning (RAR) är vår egen inbyggda kod snarare än paketerade tredjepartsbinärer, så vi kör dem också fristående mot de dedikerade verktygen på identiska korpusar, på fyra maskiner som spänner över vad en läsare faktiskt kan tänkas äga. En tid räknas bara när utdata är byte-identisk med källinnehållet: varje RAR-siffra nedan sha256-kontrollerades mot källan, och varje reparerad fil mot den orörda uppsättningen.

RAR-uppackning: 7 arkivformer, 6 verktyg

Den föregående omgången av den här tabellen använde 100 MB till 200 MB per form, vilket var ett misstag: omkring 28 ms processtart var 40% av store-etappen, och ordningen den gav överlever inte i en realistisk storlek. Den här omgången är 1 GB innehåll per form, och det ändrar flera svar, inklusive några åt andra hållet. Arkiv skapas av officiell rar 7.23, så inget verktyg bedöms på indata från sin egen kodare, och samma byte körs på varje maskin.

Vad som finns i innehållet spelar större roll än det verkar. Ett innehåll byggt av blockkopior gör varje komprimerad form till ett minneskopieringstest; ett innehåll av ren text gör den till ett literal-och-Huffman-test; vi mätte båda och de är inte överens om vem som vinner. Så de fyra komprimerade formerna använder lika tredjedelar text, strukturerade poster och okomprimerbara byte, och de två formerna i ändarna av det intervallet är separata etapper med flit: store är okomprimerbar och repetitive är nästan bara matchningar. Byggaren och testverktyget finns i förvaret, så korpusen kan återskapas byte för byte.

Omkörd 23 augusti 2026 på 1.2.2-motorn, och sveppet står kvar. De tre verktygen en läsare oftast väger - vårt, unrar 7.23 och rarpar 0.2.5 - kördes om på den 32-kärniga skrivbordsmaskinen på utgåvemotorn (uppackningskoden som körs är byte-identisk med 1.2.2-taggen), sex växlande omgångar, minimum per verktyg, varje etapps utdata kontrollerad mot innehållsmanifestet. Sekunder, lägre är bättre:

Alla sju former våra, på minimum och på medianen, 1,16x till 4,29x mot unrar. De här tiderna är inte jämförbara cell för cell med den bredare tabellen nedan - testverktyget har reviderats sedan den tabellens omgångar och omgångsantalen skiljer sig - så läs varje tabell mot sig själv. Den bredare tabellen behåller sina egna datum och sitt sexverktygsfält, och dess nzbfast-kolumn beskriver motorn 1.2.2 levererar: omkörningen ovan mätte den aktuella motorn i nivå med den tabellens bygge på alla sju former, avgjort av hårdvaruinstruktions- antal (0,14% färre för samma väggtid), så de cellerna är inte ett ersatt byggets siffror med en aktuell etikett. Den här omkörningen är också var A/A-regeln i uppläggsavsnittet intjänades. En körning samma dag rapporterade först en form som en liten regression mot vårt eget föregående bygge, och läsningen överlevde att köra båda armordningarna. En A/A-kontroll - samma binär körd mot en byte-identisk kopia av sig själv - visade att testverktyget gav vilken arm som körde först omkring en 1,5%-avgift: den identiska binären vann bara 6 av 15 omgångar från första platsen, och att kasta om ordningen tar inte ut en snedvridning som alltid drabbar den som är först. Hårdvaruinstruktionsantal avgjorde frågan testverktyget inte kunde - det nyare bygget avslutar 0,14% färre instruktioner för samma väggklocka, så det fanns ingen regression. Varje jämförelse av vårt eget bygge mot vårt eget bygge vi publicerar nu har den kontrollen.

Hela fältet, sekunder, lägre är bättre. Bäst av tre, verktygen växlade inom varje omgång snarare än körda i block, utdata kontrollerad mot källinnehållet vid varje enskild körning. Ett verktyg som gav fel byte får en korrekthetsanmärkning, aldrig en snabb tid. rarpar är Weavers egen RAR- och PAR2-kod, byggd från källkod vid bd87611; vi fäster oss vid commiten snarare än en version eftersom dess crates bär tre olika versionsnummer.

Där fältet inte kunde hänga med, och varför. ¹ 7-Zip som körs här är Homebrew-paketet, som avvisar varje komprimerad form med ERROR: Unsupported Method och läser bara den lagrade formen på macOS. En tidigare version av den här sidan skyllde det på 7-Zips macOS-bygge, vilket var fel: Homebrew bygger det utan den icke-fria unRAR-kodeken, medan macOS-bygget 7-zip.org levererar bär kodeken och avkodar alla sju former, precis som Windows-bygget gör. Ommätt 14 augusti 2026. Om du installerar 7-Zip från projektet snarare än från Homebrew beskriver den här kolumnen inte vad du har. ² bsdtar saknar RAR5-stöd för flera volymer och gav en avkortad fil utan att rapportera ett fel, så den etappen är ett korrekthetsmisslyckande snarare än en långsam tid; vårt testverktyg fångade det genom att kontrollera utdata, vilket är varför det är värt att kontrollera utdata. ³ bsdtar: Encryption is not supported. ⁴ bsdtar: Declared dictionary size is not supported. ⁵ unar levererar inget kommandoradsverktyg för Windows, så det bärbara fältet är fem. ⁶ M5 Max-gruppen kör de tre verktyg en macOS-läsare faktiskt skulle vända sig till - unrar, rarpar och vi; unar, bsdtar och 7-Zip kördes inte på den maskinen. Dess unrar är 7.22, det senaste bygget som körs obevakat där.

Varje form på varje maskin utom en, och den är oavgjord. Formerna med korta matchningar handlar om två specifika saker i vår avkodare. En matchning på två till trettiotvå byte brukade betala för ett fullt anrop till plattformens minneskopieringsrutin, och anropet kostade mer än kopian; att kopiera fasta trettiotvå byte genom ett register i stället är varför repetitive, solid och 128 MiB-ordboken - de tre formerna byggda av korta matchningar - alla är snabba på en gång. Och checksumman körs nedströms om skrivartråden snarare än på den. Den enda cell vi inte vinner rakt av är den lagrade formen på den 32-kärniga skrivbordsmaskinen, där unrar och vi är tre millisekunder isär på en etapp som bara handlar om att flytta byte - identiska vid den här tabellens precision, så båda cellerna är markerade och det poängsätts som ett oavgjort, inte en förlust och inte en vinst.

Formen vi vinner med störst marginal är den usenet faktiskt postar hundratals av åt gången: 400 små filer, 4,3× och 4,4× mot unrar och 5,4× till 5,5× mot rarpar. Det är per-medlem-parallellism, och det är skillnaden mellan en extraherare skriven för en nedladdningskö och en skriven för en kommandorad. Den lagrade formen, som kartläggningen ovan säger är 84% av byten på nätet, är nästan oavgjord för de tre seriösa verktygen, eftersom alla vid den punkten bara flyttar byte.

Ett val värt att deklarera. Arkiven packas med komprimeraren fäst vid fyra trådar. RARs blockdelning följer annars kärnantalet på vilken maskin som helst som packade arkivet, så en 32-kärnig maskin och en 20-kärnig maskin producerar olika byte från samma indata och maskinerna slutar vara jämförbara. Att fästa det gör extraktionskorpusen byte-identisk överallt, vilket är poängen, men det begränsar också hur mycket av avkodningen som kan köras parallellt - så när de två närmaste formerna var förluster körde vi om dem mot arkiv packade med alla 32 trådar, för att kontrollera att fästningen inte var orsaken. Det var den inte: solid gick från 4,2% efter till 2,4% efter och 128 MiB-ordboken från 6,6% till 6,3%, samma ordning ändå. Båda är nu vinster på den fästa korpusen med en bredare marginal än den kontrollen kunde förklara.

Varför det inte finns någon RAR4-rad, och vad som händer med de inläggen. Varje form ovan är RAR5 eller RAR7, vilket är vad usenet postar idag. Äldre RAR4-arkiv dyker fortfarande upp, och samma motor läser dem, inklusive de komprimerade och lösenordsskyddade formerna, i samma enda passage som de nyare i stället för att skriva volymerna till disk och packa upp dem efteråt. De får ingen rad här eftersom den officiella rar 7.23 inte längre kan skapa RAR4, så det finns ingen neutral korpus att köra fältet mot; det arbetet kontrolleras i stället mot arkiv skrivna av WinRAR 3.00, byte för byte mot unrar.

PAR2-verifiering och reparation: 1 GiB-uppsättning, fyra skadenivåer

Korpus: 1 GiB slumpmässigt innehåll packat i lagringsläge i 21 RAR-volymer, sedan två PAR2-uppsättningar vid 10% redundans, en vid 1 MiB-block och en vid 64 KiB, sedan fasta skadekartor. Varje körning använder samma protokoll: färsk kopia, läs hela korpusen en gång för att värma cachen, sedan tajma. Bäst av tre växlande omgångar; varje reparerad volym jämförs mot den orörda uppsättningen vid varje omgång. Lägre är bättre.

En rättelse om korpusen, eftersom en tidigare version av den här sidan överdrev den. Vi sa att varje maskin körde en byte-identisk korpus, kontrollerad med hash. Att hasha varje volym i varje uppsättning visar att det stämmer för den 32-kärniga skrivbordsmaskinen och den bärbara Windows-datorn, som matchar exakt, och inte för den 20-kärniga skrivbordsmaskinen, som håller ett annat slumpmässigt drag av samma form: samma 21 volymer i samma storlekar, samma två blockstorlekar, och skada verifierad vid samma 3, 101 och 1 500 block spridda över samma antal filer. Varje siffra inom en rad är fortfarande uppmätt på byte som varje verktyg i den raden delar, vilket är vad varje jämförelse vilar på. Men raderna är inte fyra vyer av en indata, och eftersom innehållets karaktär är värt omkring 7% för en konkurrents skanning är det värt att säga rakt ut i stället för att tona ner.

Vilken par2 som är vilken. Den ursprungliga par2cmdline är referensimplementationen alla andra har grenat från. par2cmdline-turbo är grenen som paketerar ParPars handskrivna SIMD Galois-fält-kärnor: det är exakt vad "turbo" betyder, och det är varför turbo, snarare än originalet, är verktyget värt att mäta mot. Båda turbo-kolumnerna nedan kör samma ParPar-kärnor. Det som skiljer dem är inte aritmetiken utan bygget och flaggorna.

Bekräftat på det levererade bygget mot den aktuella konkurrenten, 24 augusti 2026. De här tabellerna mättes innan 1.2.2 skars och innan par2cmdline-turbo släppte 1.5.0 (20 augusti 2026), så 20-kärnorskolumnen kördes om mot båda: vårt 1.2.2-utgåvebygge mot turbo 1.5.0, tre växlande omgångar per etapp, varje reparerad fil jämförd mot den orörda uppsättningen. Alla fyra etapper reproducerar - vårt 0,18 / 0,30 / 0,75 / 2,02 mot 0,19 / 0,33 / 0,74 / 2,07 som anges här, och turbo 1.5.0 landar inom några procent av bygget i tabellen på varje etapp och båda konfigurationer. Cellerna står som publicerade; de andra tre maskinerna behåller sina egna datum.

Så konkurrensen förekommer två gånger, och en av de kolumnerna är dess bästa fall snarare än standard. Den utgåvebinär du skulle ladda ner är kompilerad för en generisk baslinje-CPU och hashar bara ett par filer åt gången; att bygga samma källkod för den faktiska värd-CPU:n och skicka -T16 låter den använda instruktionerna den maskinen faktiskt har och hasha sexton filer åt gången. På den bärbara datorn är det värt upp till 2,6x, helt från bygge och flaggor. Bedöm oss på den finjusterade kolumnen, vilket är den svårare jämförelsen; den levererade kolumnen är vad någon som laddar ner den faktiskt upplever. par2cmdline är originalet, version 1.2.0, byggt från källkod på varje maskin. rarpar är Weavers egen PAR2-implementation, byggd från källkod med dess Metal GPU-backend aktiverad. MultiPars par2j är Windows-bara, så den visas bara på den bärbara Windows-datorns rader. M5 Max-raderna kör de två verktygen med aktuella macOS arm64-byggen bredvid de två turbo-kolumnerna; klassisk par2cmdline kördes inte på den maskinen.

Alla sexton nzbfast-celler - fyra maskiner vid fyra skadenivåer - är våra, flera med mer än 2× mot det finjusterade bygget och med 2,3× till 7,7× mot det du faktiskt skulle ladda ner. De tunga skadecellerna är de intressanta, och anmärkningen nedan förklarar algoritmen bakom dem.

Originalet är tillbaka i tabellen, och det är värt att se varför grenen finns. En tidigare version av den här sidan tog bort par2cmdline-kolumnen med motiveringen att den var långsammare än allt annat i omgången, vilket är sant och inte ett tillräckligt bra skäl: det är implementationen nästan alla andra verktyg härstammar från, och läsare förtjänar baslinjen snarare än vårt påstående om den. Vid den tyngsta skadenivån tar den omkring 69 s där SIMD-grenen tar 3,2 s och vi tar 3,1 s. Den faktorn tjugo är hela argumentet för de handskrivna Galois-fält-kärnorna, och det är samma argument vi gör för våra.

Lätt skada är fallet som spelar roll. En handfull misslyckade artiklar är mycket vanligare än 101 döda block, och inget alls som 1 500. Det mesta av en lätt reparation är inte Reed-Solomon-matematiken alls, det är att läsa och MD5:a en gigabyte, vilket är varför 3-blocksraden följer den rena verifieringsraden snarare än reparationsraderna.

Den tyngsta skadenivån är en annan sorts arbete, och den får en annan algoritm. Den sista nivån skadar 1 500 block över alla 21 volymer och förbrukar omkring 91% av återställningsdatan, vilket är där Reed-Solomon-aritmetiken, snarare än hashning eller disk, blir nästan allt arbetet. Det levererade bygget beräknar de tyngsta reparationerna med en talteoretisk transform i stället för det klassiska Galois-fält-vecket - samma matematik, evaluerad i en form som skalar mycket bättre vid höga blockantal: 2,7× före det finjusterade bygget på den 20-kärniga skrivbordsmaskinen, och på den bärbara Windows-datorn 2,7× före det finjusterade bygget och 2,2× före MultiPar. Lätt skada kör fortfarande den klassiska vägen, vilket är varför de andra nivåerna knappt rörde sig: transformen lönar sig bara över omkring 512 skadade block, så under det använder dispatchern den inte.

En snabbare väg är bara värd att ha om den inte kan ha fel. Båda vägarna beräknar samma kvantitet och är bit-identiska genom konstruktion, och varje reparation på den här sidan grindades mot att de återuppbyggda filerna matchade den orörda uppsättningen: 228 tajmade reparationer över maskinerna i den här omgången, noll felmatchningar. Det levererade bygget förlitar sig inte på det facit. Varje reparation verifierar sin egen utdata mot filhasharna, och en som misslyckades skulle göras om med den klassiska vägen automatiskt, logga avvikelsen, och behålla den klassiska vägen för resten av den körningen. Inställningen finns i instrumentpanelen som snabbt PAR-läge om du hellre skulle vara utan den helt, och maskiner med för lite minne för det avböjer det på egen hand snarare än att försöka och misslyckas. Ommätt den 2 augusti på det aktuella bygget: de två skrivbordsmaskinerna landar inom några procent av den här tabellen, och med snabbt PAR-läge avstängt faller den 20-kärniga skrivbordsmaskinen tillbaka till exakt den klassiska vägens långsammare tid, vilket säger att vinsten är metoden och inte förutsättningarna.

Den bärbara Windows-datorns kolumn behövde en rättelse, och den går emot oss. Windows degraderar uthålligt bakgrundsarbete till effektivitetskärnorna efter några sekunder. Vår daemon avstår från det vid start och ingen av de andra verktygen kan det, så en tidigare version av den här sidan publicerade deras strypta tider som om de vore verktygens egna. Att köra om den maskinen med varje verktyg lyft till hög prioritet flyttar hela fältet: på den tyngsta skadenivån går par2-turbo från 22,4 s till 6,41 och rarpar från 59,2 s till 14,4, och för en tidigare version av den här sidan vände det kolumnen från vår till en vi förlorade. Hela den bärbara kolumnen mäts nu på det sättet - rättelsen står kvar även om raden sedan dess vunnits tillbaka av algoritmändringen ovan, eftersom fältets tider på den maskinen bara är ärliga med strypningen lyft.

RAR-återställningsposter: reparation utan PAR2

När PAR2 inte kan täcka skadan är återställningsposten inuti själva RAR-arkivet den sista försvarslinjen. Fram till 1.0.8 misslyckades vårt på varje arkiv över omkring 13 MB, så den här etappen kunde inte köras alls. Skadan är tre 3 000-byte hål vid 20%, 50% och 80% genom det skyddade området. Båda verktygen gav utdata byte-identisk med den orörda filen, och vår är byte-identisk med vad rar r själv skriver. Bäst av tre, 32-kärnig skrivbordsmaskin, båda verktygen omkörda tillsammans den 2 augusti.

En tidigare version av den här sidan visade 512 MB-storleken som en förlust, och förklarade det som priset för att arbeta genom volymen i bitar snarare än att hålla allt i minnet. Den förklaringen var korrekt då och är nu föråldrad: kostnaden var en bit-seriell CRC64 i reparationsvägen, ersatt med en tabellstyrd, och förlusten försvann med den. Det finns inte längre någon korsning, och den begränsade arbetsmängden behölls. 2 GB-storleken finns här eftersom volymerna en daemon faktiskt möter är 8 GB till 20 GB, inte 512 MB, och en etapp som stannar under det verkliga intervallet inte är mycket till test.

Vad som flyttade det här snittet, och kontrollen som säger så. Att hitta vilka block som var skadade hade blivit den största fasen av den här reparationen - större än själva reparationsaritmetiken - och den kördes på en enda tråd, läsande 64 KB ur varje grupp genom hela filen, en gång per grupp. Den gör nu en sekventiell passage i filordning med checksummorna per skärva beräknade parallellt, och den reparerade volymen klonas snarare än kopieras där filsystemet kan göra det. Upptäckt ensamt föll från omkring 300 ms till 18 ms på 512 MB-arkivet, vilket är det mesta av det som flyttade ovan. Kontrollen är kolumnen bredvid vår: rar r kördes om i samma omgångar på samma maskin och kom tillbaka inom några procent av sina tidigare tider, så förändringen i gapet är vår och inte testets.

M5 Max upprepar mönstret, körd 31 juli med samma korpus och grindar: 0,050 / 0,066 / 0,171 / 0,581 s mot rar rs 0,211 / 0,335 / 0,751 / 1,735 över 16 MB till 512 MB-storlekarna - 3,0× till 5,1× snabbare; 2 GB-storleken kördes inte på den maskinen. De siffrorna föregår upptäcktsomskrivningen som beskrivs ovan, så de är det äldre byggets, behållna här som den andra maskinen snarare än som en aktuell siffra.

Weavers rarpar saknas i den här tabellen enbart, och inte av eget val: den implementerar inte den här reparationen. Ombedd att fixa ett av de här arkiven svarar den "embedded Rar5 recovery record detected ... this API restores standalone .rev recovery volumes only and does not consume embedded RR/protect data", och lämnar filen skadad. Den förekommer i varje annan jämförelse på den här sidan: alla fyra PAR2-etapper ovan, alla sju uppackningsformer ovan det, och etappen med återställningsvolymer omedelbart nedan, vilket är jobbet den säger sig göra - och som den vinner.

Återställningsvolymer: återuppbyggnad av helt saknade .rev-filer

Den andra halvan av RARs egen återställningshistoria, och fram till den här omgången den största förlusten på den här sidan. En .rev-fil är en fristående återställningsvolym: tre av dem bredvid en 21-volymsuppsättning kan återuppbygga tre volymer som aldrig anlände. Korpus: 1 GiB lagrat i 21 volymer om 50 MB med rar rv3, sedan raderades volym 4, 11 och 19 - tre förlorade mot tre återställningsvolymer, vilket är det värsta fallet uppsättningen fortfarande kan överleva. Bäst av tre, varje återuppbyggd volym jämförd mot den orörda.

Den 32-kärniga cellen här var 3,12 s mot rar rcs 0,47 i det förra snittet av den här sidan, publicerad som 6,6× långsammare och den sämsta siffran på den. Orsaken var att raderingslösningen kördes på omkring 48 MB/s återuppbyggd utdata där RARLabs klarade 320; den kör nu på samma tabellstyrda aritmetik som resten av återställningskoden, vilket är en sjufaldig förbättring och vänder förlusten till en vinst på båda maskinerna. Marginalerna är 3% och 14%, så det är en vinst att ange rakt av snarare än att göra till rubrik, och skälet till att det anges alls är att förlusten angavs först.

Den här etappen finns eftersom Weavers rarpar implementerar precis det här och bad om att mätas på det. Den vann bekvämt när vi först publicerade den, och vi publicerade den då av det skälet.

Filmatchningen var aldrig kostnaden, vilket är värt att notera eftersom det var den intuitiva misstänkta: återställningsvolymer bär inga filnamn, så vi identifierar vilka platser som överlevde genom att checksumma varje volym på disk snarare än att lita på vad de heter, och mot en oskadad uppsättning, där matchning är allt som händer, tar hela passagen 0,18 s.

Vad mer som flyttade, och var det inte syns. Två fler motorändringar landade som de här korpusarna inte kan se, listade här så att siffrorna ovan inte läses som hela historien: RAR5-arkiv med tiotusentals medlemmar löser varje medlem en gång snarare än att vandra listan per arbetare, vilket är 3× mindre processortid vid 40 000 medlemmar; och RAR1.3-bitläsaren arbetar ett ord i taget, vilket är 2×. Ingetdera visas ovan, eftersom formerna här har 400 medlemmar och ingen RAR1.3.

Vad vi medvetet inte gör: vi skapar aldrig PAR2. En nedladdare har ingen anledning att göra det, och ParPar äger den etappen. Vi köper också hastighet med minne på båda motorerna: uppackning toppar runt 240 MB mot unrars 41 MB, och verifiering runt 126 MB mot turbos 7 MB, eftersom det här är de inbyggda motorerna som rider på en pågående nedladdning snarare än att köras fristående en gång. 128 MiB-ordboksformen är det värsta av det, med omkring 304 MB mot unrars 139 MB. Den tyngsta reparationen kostar nu minne också: den snabbare metoden för 512-plus saknade block arbetar från återställningsdatan hållen resident, så den tillåts upp till en fjärdedel av maskinens RAM, begränsad till 4 GB, och en maskin som inte kan avvara det tar tyst den lågminnesmetoden i stället - samma aritmetik och samma tider som mittraderna i PAR2-tabellen, bara inte 3× på den sista. Om du vill ha minsta möjliga residenta minne för ett fristående jobb vinner de dedikerade verktygen fortfarande den kolumnen.

Transportbevis · uppmätt på 1.2.2

Motorn hänger med på verkliga linjer

• ~8,7 Gbps uthålligt genom en femprovider-flotta på en 10 GbE-linje, inklusive verifiering och uppackning i strömmen - 87 GB-omgången ovan, 24 augusti 2026, v1.2.2, 360 anslutningar: 77,4 GB nätverkstrafik på 71 s med innehållet verifierat och uppackat allteftersom det anlände. Ingen ryckvis siffra: hela jobbet vid den hastigheten.
• Vid 1 Gbit och därunder är linjen begränsningen och nzbfast sitter på den: ~96% av en 500 Mbit-linje och ~96% av en 250 Mbit-linje genom verifiering och uppackning, vid en bråkdel av varje konkurrents minne och disk - avsnittet om under-gigabit ovan.
• Hela jobbets processorkostnad på 87 GB-jobbet är 1,7 CPU-sekunder per GB med anslutningsregulatorn på - nedladdning över TLS, verifiering, reparationsberedskap och uppackning inkluderat - mot 3,0 till 28 för fältet i samma omgång; full-genomströmnings- armen ovan spenderar 4,3.

Tidigare snitt av den här sidan bar en bredare uppsättning transportdemonstrationer - flerlinjes mättnadskörningar, per-RTT-pipelinerings- vinster, ett motrycksbevis, avkodningstaks-mätningar - körda på byggen som v1.2.2 sedan dess har ersatt. Enligt den här sidans regel dras de tillbaka snarare än lämnas att åldras, och återkommer när de körs om på det aktuella släppet; de tre påståendena ovan är de som redan är ommätta på v1.2.2.