Benchmarks

Die Kurzfassung · gemessen am 23. August 2026 auf der Codelinie, die als nzbfast 1.2.2 auslief

Kein gemessener Client ist bei Prozessor, Speicher und Platte zusammen günstiger

Die neuesten Runden auf dieser Seite liefen am 23. und 24. August 2026 - die neueste davon auf dem v1.2.2-Release-Build selbst - gegen die aktuellen Builds von vier anderen Clients, auf identischer Hardware, identischen Leitungen und Providern: zwei Job-Formen von 6,5 bis 87 GB und Leitungsraten von 250 Mbit bis 10 GbE. Über diese Runden hinweg war kein Client bei Prozessor, Speicher und Platte zusammen günstiger als nzbfast: jeder kostet mehr auf mindestens zwei der drei Achsen, das Meiste, was irgendeiner auf einer einzelnen Achse sparte, waren etwa 2 Prozent - ein statistisches Unentschieden, innerhalb der eigenen Lauf-zu-Lauf-Streuung dieses Clients - und bei der Platte bewegte jeder von ihnen mindestens die doppelte Bytemenge für ein byte-identisches Ergebnis. Im Auslieferungszustand hielt nzbfast außerdem bei jedem gemessenen Client, auf jedem Testfall, den geringsten Speicherverbrauch - um das 2,0- bis 4,5-Fache gegenüber dem nächsten Konkurrenten.

Welcher Typ sind Sie?

Die meisten Downloader schreiben Ihren Download mindestens zweimal auf die Platte: einmal beim Herunterladen und noch einmal beim Entpacken. nzbfast erledigt den ganzen Job in einem Durchgang, schreibt also etwa halb so viele Bytes pro Job, hält weniger im Speicher, während es arbeitet, und braucht weniger Prozessorsekunden pro GB. Das bedeutet weniger Last auf der Maschine, während Sie sie nutzen, und halb so viele Schreibvorgänge pro Job auf Ihren Laufwerken, für dieselben byte-identischen Dateien - und weil jedes Byte die Platte nur etwa einmal durchläuft, muss Ihr Laufwerk mit Ihrer Leitung nur einmal mithalten.

nzbfast gewinnt nicht jede Tabelle auf dieser Seite, und die verlorenen stehen unter den Etappen, die wir nicht gewinnen - einschließlich einer aus diesem selben Runde. Was sich über jede von uns gemessene Runde hinweg hielt, ist die Gesamtrechnung.

Erst die Methodik

Der Aufbau

• Clients: nzbfast · SABnzbd · NZBGet · rustnzb · Weaver, jede Tabelle mit den Versionen, die sie nennt. Die neuesten Runden (23. August 2026) traten gegen die damals aktuellen Builds des Feldes an - SABnzbd 5.1.1, NZBGet 26.3-testing, rustnzb 1.4.5 und Weaver 0.7.8, dessen neuestes ausgeliefertes Binary, die Identität per Hash geprüft - gegen die Codelinie, die in derselben Nacht als nzbfast 1.2.2 auslief, sodass der Build, der die neuen Zahlen erzeugte, derselbe ist, den Sie herunterladen können. Diese Runden liefen auf einer 20-Kern-Apple-Silicon-Maschine auf einer 1 Gbit-Leitung. Ältere Tabellen behalten die Builds und Maschinen, gegen die sie antraten (Apple-M-Serien-Maschinen: „Europe"-M1-Ultra auf 10 GbE, „East Coast"-M3-Ultra mit ~2,4-3,0-Gbps-Leitung) und sagen das auch; sie stellen den ausgelieferten Build eher schlechter dar, als ihn zu schmeicheln.
• Fairness: überall dieselben Provider und TLS für jeden Client, Etappen im direkten Wechsel gefahren. Jeder Konkurrent auf sein dokumentiertes Optimum eingestellt: SABnzbd bekam pipelining_requests=8 (ausgeliefert wird 1, also ungepipelined, und die Einstellung ist bei großen Jobs zweistellige Prozentpunkte wert), NZBGet bekam ArticleCache/DirectWrite/DirectUnpack/ParQuick, rustnzb seine dokumentierte Konfiguration. Seit dem 20. August 2026 tritt jede Runde gegen fünf Provider statt sechs an - die Providerzahl ist auf diesen Maschinen kein Durchsatzhebel, wo schon ein einzelner Provider die Leitungsobergrenze erreichen kann, und eine feste Anzahl hält die Runden vergleichbar - eine Sechs-Provider-Zahl auf dieser Seite ist also nicht direkt mit einer neueren Fünf-Provider-Zahl vergleichbar, und jede Tabelle nennt, mit wie vielen sie lief.
• Endzustand: eine geprüfte, entpackte, benutzbare Datei, nicht „Download fertig". Das ist es, worauf Sie tatsächlich warten.
• Reproduzierbarkeit: jede Behauptung ist datiert und auf dieselbe Weise gemessen: verstrichene Zeit + Byte-Zähler der Schnittstelle + Spitzen-RSS des Prozessbaums, Auflösung 1-2 s. Läuft eine Etappe über eine öffentlich gepostete NZB, nennen wir sie, damit Sie sie selbst nachfahren können.
• Methodenhinweise, die seitenweit gelten: Die CPU-Zeit wird bei jedem Arm einer Tabelle mit 2 Hz aus dem Prozessbaum abgetastet und nie neben eine Zahl aus einer anderen Erfassung gestellt, weil die beiden Methoden konstruktionsbedingt nicht übereinstimmen. Geräte-E/A wird in GiB angegeben, Leitungsbytes in dezimalen GB; wir rechnen um, bevor wir dividieren. Und jede Tabelle, die unseren eigenen Build gegen unseren eigenen Build antreten lässt, führt eine A/A-Kontrolle mit - dasselbe Binary gegen eine byte-identische Kopie seiner selbst, im selben Testrahmen - weil uns diese Kontrolle darauf gebracht hat, dass unser eigener Vergleichs-Testrahmen demjenigen Tool, das zuerst lief, einen Malus von ~1,5 % zuschanzte (die Geschichte steht neben den Extraktionstabellen weiter unten). Zwei Arme und vertauschte Reihenfolgen heben eine Verzerrung, die immer auf dem ersten Arm landet, nicht auf; eine A/A-Kontrolle deckt sie auf.

Langsamere Leitungen · gemessen am 24. August 2026 mit nzbfast 1.2.2

Je langsamer die Leitung, desto weniger trennt die Clients bei der Geschwindigkeit - und desto mehr bei der Rechnung

Bei einer hinreichend langsamen Leitung ist die Fertigstellungszeit jedes Clients nur noch die Leitung selbst, nichts sonst, also verdeckt eine langsame Leitung viele Sünden. Was sie nicht verdecken kann, ist das, was jeder Client verbrennt, um sie zu füllen. Wir haben die 1-Gbit-Anlage auf zwei Raten gedrosselt, wie sie echte Pläne tatsächlich haben, und alle sechs Arme bei jeder gemessen - dieselbe Maschine, dieselben fünf Provider, drei Wiederholungen je Client mit rotierter Reihenfolge, jede Etappe byte-geprüft, 36 von 36 über beide Runden hinweg korrekt. Der nzbfast-Arm bei 500 Mbit ist der v1.2.2-Release-Build selbst.

Lesen Sie die beiden Tabellen als Gefälle. Bei 250 Mbit landet das ganze Feld innerhalb von 18 % auf der Uhr, und wir liegen 4,4 % vor dem nächsten Konkurrenten; bei 500 Mbit öffnet sich der Abstand auf 14,7 %; bei den Gigabit- und 10-GbE-Raten in den Tabellen darüber und darunter öffnet er sich weiter. Geschwindigkeitsunterschiede wachsen mit der Leitung. Die Ressourcenspalten warten nicht auf eine schnelle Leitung: bei jeder gemessenen Rate hielt jeder Konkurrent mindestens das 3,9-Fache an Speicher, verbrauchte mehr Prozessorzeit und bewegte etwa doppelt so viele Plattenbytes für dieselbe byte-identische Datei.

Der Verbindungsregler zahlt sich auf langsamen Leitungen aus, und der eigene Drop-Zähler des Shapers sagt warum. Die Werkseinstellungen hielten 25 Verbindungen, wo jeder Konkurrent Hunderte fuhr; dasselbe Binary mit abgeschaltetem Regler fuhr 360. Weniger Flüsse durch eine feste Warteschlange bedeuten weniger Verlust und weniger erneutes Senden: der Shaper verzeichnete etwa 4.200 Drops je gedeckelter Etappe gegen etwa 155.000 ungedeckelte bei 500 Mbit, und der gedeckelte Arm war schneller, 4,2x leichter beim Speicher und 1,3x leichter bei der CPU als unsere eigene 360-Socket-Haltung. Mehr Verbindungen bedeutet nicht mehr Geschwindigkeit; unterhalb eines Gigabits ist messbar das Gegenteil der Fall.

Gemessen am 24. August 2026, Mediane aus drei Läufen, auf einer 20-Kern-Apple-Silicon-Maschine mit auf jede Rate gedrosselter Leitung (die gedrosselte Rate vor jeder Runde von einer unabhängigen Sonde bestätigt: 248 und 496 Mbit). Der 500-Mbit-nzbfast-Arm ist der v1.2.2-Release-Tag-Build; die 250-Mbit-Runde lief Stunden zuvor auf derselben Codelinie. Bytezahlen auf einer gedrosselten Leitung werden aus dem eigenen Zähler jedes Clients gelesen, nie aus der Netzwerkschnittstelle (der Shaper verwirft und TCP sendet erneut, sodass die Schnittstelle beide Kopien zählt). Wanduhrzeiten sind innerhalb jeder Tabelle vergleichbar, nicht über unterschiedlich gedrosselte Runden hinweg. ¹ NZBGets drei Läufe bei 500 Mbit streuten von 114-158 s bei flachen Ressourcenwerten - eine echte Streuung, daher wird der Median angegeben und die Streuung genannt, statt sie zu verengen.

Der beschädigte Post · erneut angetreten am 24. August 2026, jeder Build aktuell

Wenn der Post Löcher hat: 6,5 GB mit 60, 20 und 5 toten Artikeln

Artikel laufen ab, Server verwerfen sie still, Uploads landen unvollständig - und Schaden ist dort, wo der Abstand zwischen Clients am größten ist, deshalb bekommt er seine eigene Runde auf dem neuesten Build jedes Clients, nzbfast v1.2.2 eingeschlossen: 10-GbE-Maschine, fünf Provider, 100 Verbindungen je Client, dasselbe 6,5-GB-Release auf drei Schadstufen vergiftet, drei Wiederholungen je Arm mit alternierender Reihenfolge, jede Etappe gegen die saubere Datei byte-geprüft. 63 von 65 Etappen kamen byte-identisch zurück; die beiden, die es nicht taten, werden unten genannt, weil sie Ergebnisse sind.

Warum der beschädigte Post hier schnell ist. Fehlt ein Artikel, fragt ein Client normalerweise den nächsten Server, dann den nächsten, bis jeder Server ihn abgelehnt hat - ein serieller Durchlauf, dessen Ablehnungen jeweils von zehn Millisekunden bis zu ein paar Sekunden dauern, während der Download bei null steht. nzbfast hört auf zu fragen: sobald die bereits vorhandenen Wiederherstellungsdaten das noch Fehlende abdecken, repariert es sofort, statt den Durchlauf zu Ende zu führen. Das ist die zweite Zeile - dasselbe Binary mit diesem abgeschalteten Verhalten ist je nach Schaden 1,4x bis 2,3x langsamer -, und die Runde bestätigte, dass der Mechanismus bei jeder aktivierten Etappe griff und nie bei einer deaktivierten. Gegen den nächsten Konkurrenten beträgt der Abstand 2,4x bis 2,7x, ohne Überlappung in einem der neun Wiederholungspaare.

Bei der Platte ist der Abstand am größten, und das liegt nicht am Reparaturtrick. Jeder abschließende Arm erzeugte dieselbe 6,48-GB-Datei; unserer bewegte dafür 6,2-6,8 GB Platten-E/A, NZBGet 12,7-18,5 GB, SABnzbd 13,9-20,3 GB und rustnzb 12,8-13,1 GB. Das ist die Ein-Durchgang-Pipeline - die abgeschaltete Zeile bewegt dieselben 6,2 GB -, sie gilt also gleichermaßen für beschädigte wie unbeschädigte Posts.

¹ SABnzbds drei Läufe beim schwersten Schaden liefen 43, 41 und 60 s - eine echte Streuung bei identischen Eingaben, daher wird der Mittelwert mit der genannten Spanne angegeben. ² rustnzb 1.4.5 lieferte jede Etappe byte-korrekt, und seine Kosten liegen bei der Prozessorzeit statt bei der Zuverlässigkeit: etwa 1.620 CPU-Sekunden gegen eine Uhrzeit von 107 s beim schwersten Schaden - rund fünfzehn Kerne die ganze Etappe über beschäftigt -, wo dieselbe reparierte Ausgabe uns etwa 50 CPU-Sekunden kostet. ³ Weaver bewegte 1,5 GB und 4,9 GB der 6,5 innerhalb unseres 20-Minuten-Limits bei den beiden schwereren Schadstufen - dasselbe Nicht-fertig-Werden in allen drei Runden, die es je bestritten hat, an drei verschiedenen Abenden; das Limit ist unseres, das Nicht-fertig-Werden ist das Ergebnis. Bei 5 toten Artikeln schloss es alle drei Male korrekt ab. Seine Prozessorkosten dort sind eine eigene Geschichte: etwa 2.325 CPU-Sekunden für die 194-s-Etappe, gegen unsere 20.

Gemessen am 24. August 2026, alle Builds aktuell: nzbfast v1.2.2 (der Release-Tag selbst), NZBGet 26.3-testing (Build vom 20. August), SABnzbd 5.1.1, rustnzb 1.4.5, Weaver 0.7.8. Ein Kontinuitätsarm trat mit dem nzbfast-Build der Vornacht innerhalb derselben Runde an und landete bei jedem Testfall innerhalb einer Sekunde von v1.2.2, sodass hier nichts auf einer glücklichen Nacht reitet; und die Konkurrenzkonfigurationen unterscheiden sich von denen der vorigen Runde nur im Anwendungspfad, Schlüssel für Schlüssel vor der Runde geprüft.

Speicher knapphalten · gemessen am 24. August 2026 mit nzbfast 1.2.2

Die Low-Memory-Leiter: 87 GB in ~0,3 GB RAM

Derselbe 87-GB-Job wie in der Runde oben, erneut gefahren mit festen Speicherbudgets von 2 GB, 1 GB und 256 MB - was die Auto-Bemessung auf einer 8-GB-Maschine, einer 4-GB-Maschine und einem 2-GB-NAS wählen würde. Jede Etappe erzeugte die identische byte-geprüfte Datei, und die Speicherspalte folgte dem Budget, nie dem Job:

Ein Lauf je Budget auf dem Release-Build, gegen dieselbe Ausgabe-Prüfsumme wie die Sechs-Arme-Runde abgesichert. Das engste Budget kostet etwa 9 % der Wanduhrzeit, und nur weil diese Leitung 10 GbE ist - ausgelagerte Blöcke kosten nur dann Zeit, wenn die Leitung die Platte überholt, auf einer typischen Heimleitung ist ein kleines Budget also nahezu kostenlos. Die ganze Leiter, einen 87-GB-Download eingeschlossen, passt in 0,3-0,6 GB Speicher; bei Werkseinstellungen lief der Job in 286 MB. Kein anderer Client bietet ein hartes prozessweites Speicherbudget; das Nächstliegende sind Cache-Größen-Regler, und die Runde unten misst, was die kosten.

Der Deckel angetreten gegen die eigenen Regler des Feldes. Beim 34-GB-Testfall (23. August 2026, 1-Gbit-Maschine, fünf Provider, 30 von 30 Etappen byte-korrekt) verdoppelte das Halten von NZBGet auf einen gleichwertigen Cache-Deckel mehr als seine CPU (215,5 auf 453,0 CPU-Sekunden, 2,10x), um einen Rückgang seines Spitzenspeichers um 52 % zu erkaufen, und SABnzbds Deckel war nahezu kostenlos, erreichte aber nur einen Teil seines Fußabdrucks. rustnzbs Cache-Einstellung war im getesteten Build dekorativ, und Weaver hat gar keinen Speicherregler, sodass beide ungedeckelt als Referenzspalten liefen, statt gegen ein Budget bewertet zu werden, das sie nicht halten können. Unsere eigene Seite jener Runde wird von der v1.2.2-Leiter oben abgelöst, die dasselbe beim 2,5-Fachen der Größe sagt: das Budget ist nie die bindende Beschränkung, weil Ein-Durchgang von vornherein so wenig hält.

Freier Speicherplatz · auf das Megabyte genau gemessen

Wie wenig freien Speicherplatz ein Job braucht

Ein Client, der auslagert und dann entpackt, braucht Platz für die Archivteile und die entpackte Nutzlast gleichzeitig, ein Job startet also nicht ohne rund das Doppelte des Downloads frei. Ein-Durchgang braucht die Nutzlast - und diese Runde maß, wie viel mehr, indem das Zielvolumen verkleinert wurde, bis jeder Client scheiterte. nzbfasts Antwort ist eine Konstante von rund 50 MB Puffer, kein Verhältnis, und das gilt von einem 6,5-GB-Job bis zu einem 34-GB-Job.

Gemessen auf einer 20-Kern-Apple-Silicon-Maschine, 1-Gbit-Leitung, fünf Provider, drei Wiederholungen an jeder Grenze, jede abgeschlossene Etappe byte-geprüft - die Konkurrenzzeilen vom 22.-23. August 2026 (Weavers 34-GB-Zelle am 24. August erneut gelaufen, Fußnote 1), und die nzbfast-Zeile am 24. August erneut auf dem v1.2.2-Release-Build geschnitten, was beide Grenzen exakt reproduzierte, 12 von 12 Etappen über beide Testfälle hinweg einhellig. Unsere Zellen sind eine gemessene Untergrenze: der Job schließt 3 von 3 mit 48,6 MB und 51,0 MB Puffer ab und verweigert 3 von 3 etwa 17 MB darunter - die Grenze ist also in beide Richtungen real. Was der Job tatsächlich hält, pendelt sich bei der Ausgabe plus etwa 3 MB ein; der Puffer bezahlt die letzten Momente der Pipeline, nie eine zweite Kopie. Die Zellen der Konkurrenten sind ihre gemessene Untergrenze beim 6,5-GB-Job und eine bestätigte Hinlänglichkeit beim selben Verhältnis beim 34-GB-Job (3 von 3 byte-korrekt bei genau diesem Verhältnis); wir haben ihre Leiter bei der größeren Größe nicht weiter nach unten abgeschritten, ihre wahre Untergrenze dort könnte also etwas unter dem Verhältnis liegen, und wir sagen das, statt zu unseren eigenen Gunsten zu runden.

Wie ein Volllaufen tatsächlich aussieht, zählt genauso viel wie die Zahl. 17 MB unter seiner Untergrenze trifft nzbfast auf die Ablehnung der Platte bei einem Schreibvorgang, hält sauber an mit „kein Speicherplatz mehr frei", behält alles, was gelandet ist, journalisiert, und ein erneuter Versuch nimmt den Faden auf, ohne erneut zu laden - ein Teilergebnis, das Sie behalten, kein gescheiterter Job. ¹ Weavers Zelle beim großen Testfall wurde durch einen erneuten Lauf am 24. August geklärt: drei von drei Etappen byte-korrekt beim selben ~2,25-Fachen, jede davon schneller als die gute Etappe des ersten Versuchs, bei bis aufs Byte identischem freiem Speicher. Beim ersten Versuch, am 23. August, waren zwei seiner drei Etappen bei einstelligen MB/s mit mehr als 60 GB noch frei ins Stocken geraten und hatten das 40-Minuten-Limit der Runde erreicht. Dieses Stocken kam nicht wieder, und die Stockungs-Instrumentierung des Prüfstands war auf allen drei Etappen des erneuten Laufs aktiv und still, was eine positive Messung ist und keine fehlende. Was es verursacht hat, ist weiterhin unbekannt, und ein sauberer erneuter Lauf ist keine Diagnose: es gibt jetzt sechs Etappen bei diesem Verhältnis, vier davon abgeschlossen, und beide Ausfälle stammen aus einem einzigen 80-Minuten-Fenster in der ersten Nacht.

Verschachtelte Beiträge · gemessen am 28. August 2026

Zehn Arten, einen Beitrag zu verpacken, und wer die Datei wirklich erreicht

Vieles, was veröffentlicht wird, ist absichtlich schwer zu öffnen. Der echte Dateiname steckt in einem zweiten Archiv, manchmal einem dritten, manchmal auf jeder Ebene in einem anderen Format, damit der Beitrag so wenig wie möglich über seinen Inhalt verrät. Hinzu kommt, dass Beiträge beschädigt ankommen: Artikel verfallen, Uploads landen unvollständig, und die Wiederherstellungsdaten müssen benutzt werden, bevor überhaupt etwas entpackt werden kann. Ein Downloader geht diese Kette für Sie durch, oder er übergibt Ihnen einen Ordner voller Archive und hört auf.

Wir haben deshalb zehn Formen gebaut, die genau das isolieren, jeden aktuellen Client dagegen antreten lassen und dann getan, was Vergleichstests sonst auslassen: Wo ein Client zu früh aufhörte, haben wir die Arbeit von Hand mit den Standardwerkzeugen beendet und auch das gemessen. Ein Client, der schnell aufgibt, wirkt schnell, bis man die Arbeit zählt, die er Ihnen hinterlässt.

nzbfast ist der Einzige, der alle zehn ohne Hilfe schafft. NZBGet erreicht die Datei ebenfalls bei jeder Form, braucht dafür aber 16 Durchgänge manueller Reparatur und Entpackung bei acht davon. SABnzbd schafft fünf ohne Hilfe, zwei bleiben auch von Hand unerreichbar. Weaver erreicht die Datei bei zweien.

Das Muster ist nicht zufällig. Die Formen, die nzbfast durchläuft und die anderen nicht, sind die verpackten und die beschädigten: ein Archiv im Archiv, ein Formatwechsel auf halbem Weg, eine fünfstufige Kette und vor allem ein Archiv, das beschädigt ankommt und seine eigenen Wiederherstellungsdaten mitbringt. Bei Letzterem entpacken vier Clients den äußeren Satz einwandfrei, übergeben Ihnen das defekte Archiv samt dem Wiederherstellungssatz, der es reparieren würde, und hören auf.

Wo Clients dieselbe Arbeit erledigen, ist der Abstand deutlich. Dies sind die sieben Formen, die alle vier verbreiteten Clients erreichen, einschließlich der jeweils nötigen manuellen Reparatur:

Vier- bis fünfmal schneller, bei weniger als der Hälfte der geschriebenen Bytes. Der Festplattenwert ist der, der nach dem Download weiter zählt: Jedes Gigabyte in dieser Spalte ist ein Gigabyte, das Ihr Laufwerk aufnehmen musste, und die Clients, die den Auftrag zwischenspeichern, schreiben die Nutzdaten heraus, lesen sie zurück und schreiben sie erneut.

Wo wir nicht vorn liegen, und warum das gesagt gehört. Bei vier der zehn Formen schreibt ein Mitbewerber während des Downloads selbst weniger Bytes als nzbfast. Jedes Mal, weil er weniger getan hat: Bei der Form mit beschädigtem Innenarchiv schreibt NZBGet 3,29 GB gegenüber unseren 4,65, dann schreibt sein Reparaturdurchgang weitere 2,91 und endet bei 6,20 GB gegenüber unseren 4,65. Bei den übrigen ist der Client, der am wenigsten geschrieben hat, einer, der die Datei nie erreicht hat. Ein kleiner Festplattenwert ist nicht immer Sparsamkeit.

Das sind Fähigkeitstests, keine Geschwindigkeitstests. Die Nutzdaten sind klein und werden aus dem Arbeitsspeicher über eine lokale Verbindung geliefert, ohne Provider und ohne Netzwerk dazwischen. Nichts hier wird durch die Downloadgeschwindigkeit begrenzt, und die absoluten Sekunden sind weit kürzer, als dieselben Formen in der Praxis brauchen würden. Ob eine Form überhaupt Handarbeit erfordert, ist eine Eigenschaft der Form und des Clients und lässt sich direkt übertragen. Die Sekunden vergleichen Clients bei identischer Arbeit, sie sagen nicht voraus, wie lange ein echter Auftrag dauert.

Vollständige Ergebnisse je Form, die Beschreibung jeder Form und die Methode finden Sie auf der Datenseite zu verschachtelten Archiven.

Warum es zählt

Ihr Laufwerk leistet die halbe Arbeit

Flash-Speicher nutzt sich durchs Beschreiben ab. Ein 94 GB großes Release kostet Ihr Laufwerk unter nzbfast etwa 90 GB an Schreibvorgängen; bei einem Client, der auslagert und entpackt, kostet dasselbe Release etwa das Doppelte. Auf einem NAS mit Festplatten entfernt die Ein-Durchgang-Form außerdem den langen einsträngigen Durchgang am Ende jedes verschlüsselten Downloads - eine Pause, gemessen bei 20 Sekunden auf einer schnellen 32-Kern-Workstation mit hardwarebeschleunigter Entriegelung, und entsprechend länger auf den stromsparenden Maschinen, auf denen die meisten Leute das tatsächlich betreiben. Wir zitieren die kleine Zahl, weil es die ist, die wir gemessen haben.

Komponenten-Vergleiche

Die technischeren Benchmarks, für alle, die mehr Daten mögen

Reparatur (PAR2) und Entpacken (RAR) sind unser eigener nativer Code statt gebündelter Fremd-Binaries, deshalb lassen wir sie auch eigenständig gegen die dedizierten Werkzeuge auf identischen Korpora antreten, auf vier Maschinen, die abdecken, was ein Leser tatsächlich besitzen könnte. Eine Zeit zählt nur, wenn die Ausgabe byte-identisch zur Quell-Nutzlast ist: jede RAR-Zahl unten wurde per sha256 gegen die Quelle geprüft, und jede reparierte Datei gegen den unversehrten Satz.

RAR-Extraktion: 7 Archivformen, 6 Werkzeuge

Die vorige Runde dieser Tabelle nutzte 100 MB bis 200 MB je Form, was ein Fehler war: etwa 28 ms Prozessstart waren 40 % der gespeicherten Etappe, und die Reihenfolge, die dabei herauskam, überlebt bei realistischer Größe nicht. Diese Runde nutzt 1 GB Nutzlast je Form, und das ändert mehrere Antworten, einige davon in die andere Richtung. Archive werden mit dem offiziellen rar 7.23 erzeugt, damit kein Werkzeug an Eingaben aus seinem eigenen Encoder gemessen wird, und dieselben Bytes treten auf jeder Maschine an.

Was in der Nutzlast steckt, zählt mehr, als es aussieht. Eine aus Blockkopien gebaute Nutzlast macht jede komprimierte Form zu einem Speicherkopier-Benchmark; eine Nutzlast aus reinem Text macht sie zu einem Literal-und-Huffman-Benchmark; wir haben beides gemessen, und sie stimmen nicht darin überein, wer gewinnt. Die vier komprimierten Formen nutzen deshalb gleiche Drittel aus Text, strukturierten Datensätzen und inkompressiblen Bytes, und die zwei Formen an den Enden dieser Spanne sind absichtlich eigene Etappen: store ist inkompressibel und repetitive besteht fast nur aus Treffern. Der Baugenerator und der Testrahmen liegen im Repository, der Korpus lässt sich also byte für byte neu aufbauen.

Am 23. August 2026 erneut auf der 1.2.2-Engine angetreten, und der Sweep hält stand. Die drei Werkzeuge, die ein Leser am ehesten gegeneinander abwägt - unseres, unrar 7.23 und rarpar 0.2.5 - traten erneut auf dem 32-Kern-Desktop auf der Release-Engine an (der getestete Extraktionscode ist byte-identisch mit dem 1.2.2-Tag), sechs verschränkte Runden, Minimum je Werkzeug, jede Etappenausgabe gegen das Nutzlast-Manifest geprüft. Sekunden, niedriger ist besser:

Alle sieben Formen gehen an uns, sowohl beim Minimum als auch beim Median, 1,16x bis 4,29x gegen unrar. Diese Zeiten sind nicht Zelle für Zelle mit der breiteren Tabelle unten vergleichbar - der Testrahmen wurde seit deren Runden überarbeitet, und die Rundenzahlen unterscheiden sich -, lesen Sie also jede Tabelle für sich. Die breitere Tabelle behält ihre eigenen Daten und ihr Sechs-Werkzeuge-Feld, und ihre nzbfast-Spalte beschreibt die Engine, die 1.2.2 ausliefert: das erneute Antreten oben maß die aktuelle Engine gleichauf mit dem Build jener Tabelle auf allen sieben Formen, entschieden über Hardware-Instruktionszahlen (0,14 % weniger für dieselbe Wanduhrzeit), diese Zellen sind also nicht die Zahlen eines abgelösten Builds unter aktuellem Etikett. Dieses erneute Antreten ist auch der Ort, an dem sich die A/A-Regel im Aufbau-Abschnitt verdient hat. Ein gleichtägiger Durchlauf meldete zunächst eine Form als kleine Regression gegen unseren eigenen vorigen Build, und der Befund überlebte das Fahren beider Armreihenfolgen. Eine A/A-Kontrolle - dasselbe Binary gegen eine byte-identische Kopie seiner selbst - zeigte, dass der Testrahmen demjenigen Arm, der zuerst lief, einen Malus von etwa 1,5 % zuschanzte: das identische Binary gewann nur 6 von 15 Runden vom ersten Platz aus, und vertauschte Reihenfolgen heben eine Verzerrung, die immer auf demjenigen landet, der zuerst dran ist, nicht auf. Hardware-Instruktionszahlen entschieden die Frage, die der Testrahmen nicht klären konnte - der neuere Build zieht 0,14 % weniger Instruktionen für dieselbe Wanduhrzeit, es gab also keine Regression. Jeder von uns veröffentlichte Vergleich unseres eigenen Builds gegen unseren eigenen Build trägt diese Kontrolle jetzt.

Das ganze Feld, Sekunden, niedriger ist besser. Bester von drei, Werkzeuge innerhalb jeder Runde verschränkt statt in Blöcken gefahren, Ausgabe bei jedem einzelnen Lauf gegen die Quell-Nutzlast geprüft. Ein Werkzeug, das die falschen Bytes lieferte, bekommt einen Korrektheitshinweis, nie eine schnelle Zeit. rarpar ist Weavers eigener RAR- und PAR2-Code, aus dem Quelltext bei bd87611 gebaut; wir pinnen den Commit statt einer Version, weil seine Crates drei verschiedene Versionsnummern tragen.

Wo das Feld nicht mithalten konnte, und warum. ¹ Das hier getestete 7-Zip ist das Homebrew-Paket, das jede komprimierte Form mit ERROR: Unsupported Method ablehnt und auf macOS nur die gespeicherte Form liest. Eine frühere Version dieser Seite schrieb das 7-Zips macOS-Build zu, was falsch war: Homebrew baut es ohne den nicht-freien unRAR-Codec, während das macOS-Build von 7-zip.org den Codec mitbringt und alle sieben Formen dekodiert, wie es das Windows-Build tut. Erneut gemessen am 14. August 2026. Wenn Sie 7-Zip vom Projekt statt von Homebrew installieren, beschreibt diese Spalte nicht, was Sie haben. ² bsdtar hat keine RAR5-Mehrteil-Unterstützung und lieferte eine abgeschnittene Datei, ohne einen Fehler zu melden, diese Etappe ist also ein Korrektheitsversagen statt einer langsamen Zeit; unser Testrahmen fing das ab, indem er die Ausgabe prüfte, weshalb es sich lohnt, die Ausgabe zu prüfen. ³ bsdtar: Encryption is not supported. ⁴ bsdtar: Declared dictionary size is not supported. ⁵ unar liefert kein Windows-Kommandozeilenwerkzeug aus, das Laptop-Feld ist also fünf. ⁶ Die M5-Max-Gruppe lässt die drei Werkzeuge antreten, zu denen ein macOS-Leser tatsächlich greifen würde - unrar, rarpar und wir; unar, bsdtar und 7-Zip traten auf dieser Maschine nicht an. Ihr unrar ist 7.22, der neueste Build, der dort unbeaufsichtigt läuft.

Jede Form auf jeder Maschine bis auf eine, und die ist ein Unentschieden. Die Formen mit kurzen Treffern kommen auf zwei bestimmte Dinge in unserem Decoder herunter. Ein Treffer von zwei bis zweiunddreißig Bytes bezahlte früher für einen vollen Aufruf der Speicherkopierroutine der Plattform, und der Aufruf kostete mehr als das Kopieren; stattdessen feste zweiunddreißig Bytes über ein Register zu kopieren ist, warum repetitive, solid und das 128-MiB-Wörterbuch - die drei aus kurzen Treffern gebauten Formen - alle auf einmal schnell sind. Und die Prüfsumme läuft dem Thread des Schreibers nach statt auf ihm. Die eine Zelle, die wir nicht klar gewinnen, ist die gespeicherte Form auf dem 32-Kern-Desktop, wo unrar und wir drei Millisekunden auseinanderliegen, bei einer Etappe, die rein Bytes bewegt - bei der Genauigkeit dieser Tabelle identisch, also sind beide Zellen markiert, und es zählt als Unentschieden, nicht als Verlust und nicht als Sieg.

Die Form, die wir am deutlichsten gewinnen, ist die, von der Usenet tatsächlich Hunderte auf einmal postet: 400 kleine Dateien, 4,3× und 4,4× gegen unrar und 5,4× bis 5,5× gegen rarpar. Das ist Parallelität pro Mitglied, und das ist der Unterschied zwischen einem Extraktor, der für eine Download-Warteschlange geschrieben wurde, und einem, der für eine Kommandozeile geschrieben wurde. Die gespeicherte Form, die laut der Zählung oben 84 % der Bytes auf der Leitung ausmacht, ist für die drei ernsthaften Werkzeuge ein nahes Unentschieden, weil an dieser Stelle jeder nur Bytes bewegt.

Eine Entscheidung, die es wert ist, genannt zu werden. Die Archive werden mit dem Kompressor fest auf vier Threads gepackt. Der Blocksplit von RAR folgt sonst der Kernzahl der packenden Maschine, sodass eine 32-Kern-Maschine und eine 20-Kern-Maschine aus derselben Eingabe verschiedene Bytes erzeugen und die Maschinen nicht mehr vergleichbar sind. Das Fixieren macht den Extraktionskorpus überall byte-identisch, das ist der Sinn, deckelt aber auch, wie viel vom Decodieren parallel laufen kann - als also die beiden nächstliegenden Formen Verluste waren, traten wir erneut gegen Archive an, die mit allen 32 Threads gepackt waren, um zu prüfen, dass nicht das Fixieren die Ursache war. War es nicht: solid rückte von 4,2 % Rückstand auf 2,4 % Rückstand, und das 128-MiB-Wörterbuch von 6,6 % auf 6,3 %, dieselbe Reihenfolge so oder so. Beide sind auf dem fixierten Korpus jetzt Siege, mit größerem Abstand, als diese Prüfung erklären könnte.

Warum es keine RAR4-Zeile gibt, und was mit diesen Posts passiert. Jede Form oben ist RAR5 oder RAR7, was Usenet heute postet. Ältere RAR4-Archive tauchen immer noch auf, und dieselbe Engine liest sie, komprimierte und passwortgeschützte Formen eingeschlossen, in demselben einzigen Durchgang wie die neueren, statt die Volumes auf die Platte zu schreiben und sie danach zu entpacken. Sie bekommen hier keine Zeile, weil das offizielle rar 7.23 kein RAR4 mehr erzeugen kann, es gibt also keinen neutralen Korpus, um das Feld antreten zu lassen; diese Arbeit wird stattdessen gegen von WinRAR 3.00 geschriebene Archive geprüft, byte für byte gegen unrar.

PAR2-Prüfung und -Reparatur: 1-GiB-Satz, vier Schadstufen

Korpus: 1 GiB Zufalls-Nutzlast, store-gepackt in 21 RAR-Volumes, dann zwei PAR2-Sätze bei 10 % Redundanz, einer mit 1-MiB-Blöcken und einer mit 64 KiB, dann feste Schadenskarten. Jeder Lauf nutzt dasselbe Protokoll: frische Kopie, den ganzen Korpus einmal lesen, um den Cache aufzuwärmen, dann messen. Bester von drei verschränkten Runden; jedes reparierte Volume wird bei jeder Runde gegen den unversehrten Satz geprüft. Niedriger ist besser.

Eine Korrektur zum Korpus, weil eine frühere Version dieser Seite ihn überzeichnet hatte. Wir sagten, jede Maschine fährt einen byte-identischen, per Hash geprüften Korpus. Jedes Volume jedes Satzes zu hashen zeigt, dass das für den 32-Kern-Desktop und den Windows-Laptop stimmt, die exakt übereinstimmen, und nicht für den 20-Kern-Desktop, der einen anderen Zufallszug derselben Form hält: dieselben 21 Volumes in denselben Größen, dieselben zwei Blockgrößen, und der Schaden bei denselben 3, 101 und 1.500 Blöcken geprüft, verteilt über dieselbe Anzahl Dateien. Jede Zahl innerhalb einer Zeile ist noch immer an Bytes gemessen, die jedes Werkzeug in dieser Zeile teilt, worauf jeder Vergleich beruht. Aber die Zeilen sind nicht vier Ansichten einer Eingabe, und da der Charakter der Nutzlast einem Konkurrenten beim Scannen etwa 7 % wert ist, lohnt es sich, das zu sagen, statt es zu übertünchen.

Welches par2 welches ist. Das ursprüngliche par2cmdline ist die Referenzimplementierung, von der jeder andere abgeleitet ist. par2cmdline-turbo ist der Fork, der ParPars handgeschriebene SIMD-Galoisfeld-Kernel mitbringt: genau das bedeutet „turbo", und deshalb ist turbo, statt des Originals, das Werkzeug, das es wert ist, gegen uns gemessen zu werden. Beide Turbo-Spalten unten laufen mit denselben ParPar-Kernen. Was sie trennt, ist nicht die Arithmetik, sondern der Build und die Flags.

Am 24. August 2026 auf dem ausgelieferten Build gegen den aktuellen Konkurrenten bestätigt. Diese Tabellen wurden gemessen, bevor 1.2.2 geschnitten wurde und bevor par2cmdline-turbo 1.5.0 veröffentlichte (20. August 2026), also trat die 20-Kern-Spalte erneut gegen beide an: unser 1.2.2-Release-Build gegen turbo 1.5.0, drei verschränkte Runden je Etappe, jede reparierte Datei gegen den unversehrten Satz geprüft. Alle vier Etappen reproduzieren sich - unsere 0,18 / 0,30 / 0,75 / 2,02 gegen die hier gedruckten 0,19 / 0,33 / 0,74 / 2,07, und turbo 1.5.0 landet bei jeder Etappe und beiden Konfigurationen innerhalb weniger Prozent vom Build in der Tabelle. Die Zellen bleiben wie veröffentlicht stehen; die anderen drei Maschinen behalten ihre eigenen Daten.

Die Konkurrenz erscheint also zweimal, und eine dieser Spalten ist ihr Best-Case statt ihre Voreinstellung. Das Release-Binary, das Sie herunterladen würden, ist für eine generische Baseline-CPU kompiliert und hasht nur ein paar Dateien gleichzeitig; dieselbe Quelle für die tatsächliche Host-CPU zu bauen und -T16 zu übergeben, lässt es die Instruktionen nutzen, die diese Maschine wirklich hat, und sechzehn Dateien gleichzeitig hashen. Auf dem Laptop ist das bis zu 2,6x wert, allein von Build und Flags. Beurteilen Sie uns anhand der abgestimmten Spalte, das ist der härtere Vergleich; die Spalte „wie ausgeliefert" ist das, was jemand erlebt, der es herunterlädt. par2cmdline ist das Original, Version 1.2.0, auf jeder Maschine aus dem Quelltext gebaut. rarpar ist Weavers eigene PAR2-Implementierung, aus dem Quelltext mit aktiviertem Metal-GPU-Backend gebaut. MultiPars par2j ist Windows-only, es erscheint also nur in den Windows-Laptop-Zeilen. Die M5-Max-Zeilen lassen die beiden Werkzeuge mit aktuellen macOS-arm64-Builds neben den beiden Turbo-Spalten antreten; das klassische par2cmdline trat auf dieser Maschine nicht an.

Alle sechzehn nzbfast-Zellen - vier Maschinen bei vier Schadstufen - gehen an uns, mehrere um mehr als das 2× gegen den abgestimmten Build und um das 2,3× bis 7,7× gegen das, was Sie tatsächlich herunterladen würden. Die Zellen mit schwerem Schaden sind die interessanten, und der Hinweis unten erklärt den Algorithmus dahinter.

Das Original ist zurück in der Tabelle, und es lohnt sich zu sehen, warum der Fork existiert. Eine frühere Version dieser Seite ließ die Spalte par2cmdline weg, mit der Begründung, sie sei langsamer als alles andere in der Runde, was stimmt und kein guter genug Grund ist: es ist die Implementierung, von der fast jedes andere Werkzeug abstammt, und Leser verdienen die Baseline statt unserer Behauptung darüber. Auf der schwersten Schadstufe braucht es etwa 69 s, wo der SIMD-Fork 3,2 s braucht und wir 3,1 s. Dieser Faktor zwanzig ist das ganze Argument für die handgeschriebenen Galoisfeld-Kernel, und es ist dasselbe Argument, das wir für unsere machen.

Leichter Schaden ist der Fall, der zählt. Eine Handvoll ausgefallener Artikel ist weit typischer als 101 tote Blöcke, und nichts wie 1.500. Der größte Teil einer leichten Reparatur ist gar nicht die Reed-Solomon-Mathematik, sondern das Lesen und MD5-Bilden eines Gigabytes, weshalb die 3-Block-Zeile eher der sauberen Prüfzeile folgt als den Reparaturzeilen.

Die schwerste Schadstufe ist eine andere Art Arbeit, und sie bekommt einen anderen Algorithmus. Diese letzte Stufe beschädigt 1.500 Blöcke über alle 21 Volumes hinweg und verbraucht etwa 91 % der Wiederherstellungsdaten, das ist der Punkt, an dem die Reed-Solomon-Arithmetik statt Hashing oder Platte fast die ganze Arbeit ausmacht. Der ausgelieferte Build berechnet die schwersten Reparaturen mit einer zahlentheoretischen Transformation statt der klassischen Galoisfeld-Faltung - dieselbe Mathematik, in einer Form ausgewertet, die bei hohen Blockzahlen deutlich besser skaliert: 2,7× vor dem abgestimmten Build auf dem 20-Kern-Desktop, und auf dem Windows-Laptop 2,7× vor dem abgestimmten Build und 2,2× vor MultiPar. Leichter Schaden läuft noch immer über den klassischen Pfad, weshalb sich die anderen Stufen kaum bewegten: die Transformation zahlt sich erst oberhalb von etwa 512 beschädigten Blöcken aus, darunter nutzt der Dispatcher sie also nicht.

Ein schnellerer Pfad ist nur etwas wert, wenn er nicht falsch sein kann. Beide Pfade berechnen dieselbe Größe und sind konstruktionsbedingt bitidentisch, und jede Reparatur auf dieser Seite wurde daran gemessen, ob die wiederhergestellten Dateien mit dem unversehrten Satz übereinstimmten: 228 zeitgemessene Reparaturen über die Maschinen dieser Runde, null Abweichungen. Der ausgelieferte Build verlässt sich nicht auf diese Bilanz. Jede Reparatur prüft ihre eigene Ausgabe gegen die Datei-Hashes, und eine fehlgeschlagene würde automatisch mit dem klassischen Pfad wiederholt, die Abweichung protokollieren und für den Rest dieses Laufs beim klassischen Pfad bleiben. Die Einstellung steht im Dashboard als Fast-PAR-Modus, falls Sie sie lieber gar nicht wollen, und Maschinen mit zu wenig Speicher dafür lehnen sie von sich aus ab, statt es zu versuchen und zu scheitern. Erneut gemessen am 2. August auf dem aktuellen Build: die beiden Desktops landen innerhalb weniger Prozent dieser Tabelle, und mit abgeschaltetem Fast-PAR-Modus fällt der 20-Kern-Desktop auf exakt die langsamere Zeit des klassischen Pfads zurück, was zeigt, dass der Sieg an der Methode liegt und nicht an den Bedingungen.

Die Spalte des Windows-Laptops brauchte eine Korrektur, und sie geht gegen uns. Windows verschiebt anhaltende Hintergrundarbeit nach ein paar Sekunden auf seine Effizienzkerne. Unser Daemon steigt beim Start daraus aus, und keines der anderen Werkzeuge kann das, sodass eine frühere Version dieser Seite deren gedrosselte Zeiten veröffentlichte, als wären es ihre eigenen. Diese Maschine mit jedem Werkzeug auf hohe Priorität gehoben erneut zu fahren, verschiebt das ganze Feld: auf der schwersten Schadstufe geht par2-turbo von 22,4 s auf 6,41, und rarpar von 59,2 s auf 14,4, und für einen Schnitt dieser Seite machte das aus der Spalte, die uns gehörte, eine, die wir verloren. Die ganze Laptop-Spalte wird jetzt so gemessen - die Korrektur bleibt bestehen, obwohl die Zeile inzwischen durch die Algorithmusänderung oben zurückgewonnen wurde, weil die Zeiten des Feldes auf dieser Maschine nur mit angehobener Drosselung ehrlich sind.

RAR-Wiederherstellungsdatensätze: Reparieren ohne PAR2

Wenn PAR2 den Schaden nicht abdecken kann, ist der Wiederherstellungsdatensatz im RAR selbst die letzte Verteidigungslinie. Bis 1.0.8 scheiterte unseres an jedem Archiv über etwa 13 MB, diese Etappe konnte also gar nicht gefahren werden. Schaden sind drei 3.000-Byte-Löcher bei 20 %, 50 % und 80 % durch den geschützten Bereich. Beide Werkzeuge lieferten eine Ausgabe byte-identisch zur unversehrten Datei, und unsere ist byte-identisch zu dem, was rar r selbst schreibt. Bester von drei, 32-Kern-Desktop, beide Werkzeuge am 2. August gemeinsam erneut angetreten.

Eine frühere Version dieser Seite zeigte die 512-MB-Größe als Verlust und erklärte das als Preis dafür, das Volume in Teilen zu durchlaufen, statt alles im Speicher zu halten. Diese Erklärung war zu jener Zeit richtig und ist jetzt überholt: die Kosten waren eine bit-serielle CRC64 im Reparaturpfad, ersetzt durch eine tabellengesteuerte, und der Verlust verschwand mit ihr. Es gibt keinen Umschlagpunkt mehr, und die begrenzte Arbeitsmenge blieb erhalten. Die 2-GB-Größe steht hier, weil die Volumes, denen ein Daemon tatsächlich begegnet, 8 GB bis 20 GB sind, nicht 512 MB, und eine Etappe, die unterhalb des echten Bereichs endet, ist nicht viel von einem Test.

Was diesen Schnitt bewegt hat, und die Kontrolle, die das belegt. Herauszufinden, welche Blöcke beschädigt sind, war zur größten Phase dieser Reparatur geworden - größer als die Reparaturarithmetik selbst -, und sie lief auf einem einzigen Thread, 64 KB aus jeder Gruppe über die ganze Datei hinweg lesend, einmal je Gruppe. Sie macht jetzt einen einzigen sequenziellen Durchgang in Dateireihenfolge, mit den Prüfsummen je Shard parallel berechnet, und das reparierte Volume wird geklont statt kopiert, wo das Dateisystem das kann. Die Erkennung allein fiel von etwa 300 ms auf 18 ms beim 512-MB-Archiv, was das meiste von dem ist, was sich oben bewegt hat. Die Kontrolle ist die Spalte neben unserer: rar r trat in denselben Runden auf derselben Maschine erneut an und kam innerhalb weniger Prozent seiner vorigen Zeiten zurück, die Änderung im Abstand liegt also an uns, nicht an der Messbank.

Der M5 Max wiederholt das Muster, angetreten am 31. Juli mit demselben Korpus und denselben Prüfungen: 0,050 / 0,066 / 0,171 / 0,581 s gegen rar rs 0,211 / 0,335 / 0,751 / 1,735 über die Größen von 16 MB bis 512 MB - 3,0× bis 5,1× schneller; die 2-GB-Größe trat auf dieser Maschine nicht an. Diese Zahlen stammen von vor der oben beschriebenen Erkennungs-Überarbeitung, sie gehören also zum älteren Build und stehen hier als zweite Maschine, nicht als aktuelle Zahl.

Weavers rarpar fehlt allein in dieser Tabelle, und nicht aus Wahl: es implementiert diese Reparatur nicht. Gebeten, eines dieser Archive zu reparieren, antwortet es „embedded Rar5 recovery record detected ... this API restores standalone .rev recovery volumes only and does not consume embedded RR/protect data", und lässt die Datei beschädigt. Es erscheint in jedem anderen Vergleich auf dieser Seite: allen vier PAR2-Etappen oben, allen sieben Extraktionsformen davor, und der Wiederherstellungsvolume-Etappe direkt darunter, die genau der Job ist, den es zu tun behauptet - und den es gewinnt.

Wiederherstellungsvolumes: fehlende ganze .rev-Dateien rekonstruieren

Die andere Hälfte von RARs eigener Wiederherstellungsgeschichte, und bis zu dieser Runde der größte Verlust auf dieser Seite. Eine .rev-Datei ist ein eigenständiges Wiederherstellungsvolume: drei davon neben einem 21-Volume-Satz können jede beliebigen drei Volumes rekonstruieren, die nie ankamen. Korpus: 1 GiB gespeichert in 21 Volumes zu 50 MB mit rar rv3, dann Volumes 4, 11 und 19 gelöscht - drei verloren gegen drei Wiederherstellungsvolumes, der schlimmste Fall, den der Satz noch überleben kann. Bester von drei, jedes rekonstruierte Volume gegen das unversehrte geprüft.

Die 32-Kern-Zelle hier stand im letzten Schnitt dieser Seite bei 3,12 s gegen rar rcs 0,47, veröffentlicht als 6,6× langsamer und die schlechteste Zahl darauf. Die Ursache war die Erasure-Lösung, die bei etwa 48 MB/s an rekonstruierter Ausgabe lief, wo RARLabs Version 320 verwaltete; sie läuft jetzt auf derselben tabellengesteuerten Arithmetik wie der Rest des Wiederherstellungscodes, was eine siebenfache Verbesserung ist und den Verlust auf beiden Maschinen in einen Sieg verwandelt. Die Abstände betragen 3 % und 14 %, es ist also ein Sieg, den man schlicht nennt statt zur Schlagzeile macht, und der Grund, warum er überhaupt genannt wird, ist, dass der Verlust zuerst genannt wurde.

Diese Etappe existiert, weil Weavers rarpar genau das implementiert und darum bat, daran gemessen zu werden. Es gewann komfortabel, als wir es zum ersten Mal veröffentlichten, und wir veröffentlichten es damals aus diesem Grund.

Der Dateiabgleich war nie die Kostenstelle, was sich zu notieren lohnt, weil es der naheliegende Verdächtige war: Wiederherstellungsvolumes tragen keine Dateinamen, wir identifizieren also, welche Plätze überlebt haben, indem wir jedes Volume auf der Platte prüfsummen, statt dem zu vertrauen, wie sie heißen, und gegen einen unbeschädigten Satz, wo nur der Abgleich passiert, dauert der ganze Durchgang 0,18 s.

Was sich sonst noch bewegt hat, und wo es sich nicht zeigt. Zwei weitere Engine-Änderungen sind gelandet, die diese Korpora nicht sehen können, hier genannt, damit die Zahlen oben nicht als die ganze Geschichte gelesen werden: RAR5-Archive mit zehntausenden Mitgliedern lösen jedes Mitglied einmal auf, statt die Liste je Worker zu durchlaufen, das ist 3× weniger Prozessorzeit bei 40.000 Mitgliedern; und der RAR1.3-Bit-Reader arbeitet ein Wort auf einmal, das ist 2×. Keines erscheint oben, weil die Formen hier 400 Mitglieder haben und kein RAR1.3.

Was wir absichtlich nicht tun: wir erzeugen nie PAR2. Ein Downloader hat dazu keinen Grund, und ParPar besitzt diese Etappe. Wir kaufen auch bei beiden Engines Geschwindigkeit mit Speicher: die Extraktion erreicht Spitzen um 240 MB gegen unrars 41 MB, und die Prüfung um 126 MB gegen turbos 7 MB, weil das die Inline-Engines sind, die einen laufenden Download begleiten, statt eigenständige Einmal-Läufe zu sein. Die 128-MiB-Wörterbuch-Form ist das Schlimmste davon, bei etwa 304 MB gegen unrars 139 MB. Die schwerste Reparatur kostet jetzt auch Speicher: die schnellere Methode für 512 und mehr fehlende Blöcke arbeitet mit den residenten Wiederherstellungsdaten, sie darf also bis zu einem Viertel des Maschinenspeichers nutzen, gedeckelt bei 4 GB, und eine Maschine, die das nicht erübrigen kann, nimmt still die Low-Memory-Methode - dieselbe Arithmetik und dieselben Zeiten wie die mittleren Zeilen der PAR2-Tabelle, nur nicht das 3× bei der letzten. Wenn Sie den kleinstmöglichen residenten Speicher für einen eigenständigen Job wollen, gewinnen die dedizierten Werkzeuge diese Spalte immer noch.

Transportbeweis · gemessen mit 1.2.2

Die Engine hält mit echten Leitungen mit

• ~8,7 Gbps anhaltend durch eine Fünf-Provider-Flotte auf einer 10-GbE-Leitung, Prüfung und Entpacken im Datenstrom eingeschlossen - die 87-GB-Runde oben, 24. August 2026, v1.2.2, 360 Verbindungen: 77,4 GB Leitung in 71 s, mit der Nutzlast geprüft und entpackt, während sie ankam. Keine Burst-Zahl: der ganze Job auf dieser Rate.
• Bei 1 Gbit und darunter ist die Leitung das Limit, und nzbfast liegt darauf: ~96 % einer 500-Mbit-Leitung und ~96 % einer 250-Mbit-Leitung durch Prüfung und Entpacken, bei einem Bruchteil des Speichers und der Platte jedes Konkurrenten - der Subgigabit-Abschnitt oben.
• Die gesamten Prozessorkosten des Jobs beim 87-GB-Job betragen 1,7 CPU-Sekunden je GB mit eingeschaltetem Verbindungsregler - Download über TLS, Prüfung, Reparaturbereitschaft und Entpacken eingeschlossen - gegen 3,0 bis 28 für das Feld in derselben Runde; der Volldurchsatz-Arm oben verbraucht 4,3.

Frühere Schnitte dieser Seite trugen eine breitere Sammlung von Transport-Demonstrationen - Mehrleitungs-Sättigungsläufe, Pipelining-Gewinne je RTT, ein Gegendruck-Nachweis, Decode-Obergrenzen-Messungen - angetreten auf Builds, die v1.2.2 seither abgelöst hat. Nach der Regel dieser Seite werden sie zurückgezogen statt altern gelassen, und kehren zurück, sobald sie auf dem aktuellen Release neu geschnitten sind; die drei Behauptungen oben sind die, die bereits auf v1.2.2 neu gemessen wurden.