Uitgelegd · een
Het meeste van wat deze client snel maakt is geen sneller netwerkpad. Het is dat de gegevens maar één keer bewegen. Dit is wat dat in de praktijk betekent, waarom het iets anders is dan direct uitpakken, welke archiefvormen het overleven, en wat het schrappen van de schrijf-en-teruglees-cyclus op een echte machine werkelijk waard is.
Het vertrekpunt
Een post bestaat uit duizenden kleine gecodeerde artikelen die samen een reeks archiefvolumes vormen, die op hun beurt het bestand bevatten dat je eigenlijk wilt. Van het een naar het ander komen waren van oudsher vier afzonderlijke taken, elk afgerond voordat de volgende begint.
Elke fase is correct, en de uitkomst klopt. Maar de inhoud is twee keer geschreven, minstens twee keer gelezen, en op het hoogste punt moest de schijf twee volledige kopieën bevatten van een taak waarvan je er maar één wilde. De klok die jij meemaakt is alle vier de fasen op een rij, en daarom kan een client een snelle download melden en je toch laten wachten.
De verandering
One-pass betekent dat de bytes van het netwerk naar hun eindbestemming gaan zonder ooit een archiefbestand op je schijf te worden. Er is geen fase twee of drie, want het werk van allebei gebeurt terwijl fase één nog loopt.
In de praktijk wordt elk artikel zodra het binnenkomt in het geheugen gedecodeerd en meteen aan twee dingen tegelijk doorgegeven. De verificateur controleert het onmiddellijk tegen de pariteitsgegevens, zodat de juistheid vaststaat terwijl de gegevens landen in plaats van door ze later terug te lezen. De uitpakker behandelt de binnenkomende bytes als een positie binnen het archief, rekent uit bij welk deel van welk inhoudsbestand ze horen, en schrijft ze daar.
De archiefvolumes worden nooit samengesteld. Ze bestaan als een structuur die de uitpakker begrijpt terwijl de download onderweg is, en het enige dat je schijf bereikt is het bestand dat je wilde. Als het laatste artikel aankomt is er vrijwel niets meer te doen, en daarom liggen onze eindtijden dicht bij de downloadtijd zelf in plaats van bij een download plus een staart.
Het meetbare gevolg: voor dezelfde taak schrijven we ongeveer de helft, lezen we veel minder terug, en hebben we ruwweg de eigen omvang van de inhoud aan vrije ruimte nodig in plaats van het dubbele. Bij een release van 190 GB is dat ongeveer 157 GB vrije ruimte tegen ongeveer 313 GB, en ruwweg een derde van het schijfverkeer.
Twee dingen maken dit lastiger dan het klinkt, en zij zijn de reden dat het ongewoon is. Artikelen komen niet op volgorde binnen, dus de uitpakker moet omgaan met bytes die op willekeurige posities landen in plaats van als een stroom vanaf het begin. En een gecomprimeerd archief laat zich niet vanaf het midden uitpakken, dus elk deel van het werk dat echt volgorde vereist moet worden herkend en anders behandeld in plaats van weggeredeneerd.
De vergelijking waar men naar vraagt
Direct uitpakken is een goede functie en de clients die haar hebben zijn er beter mee af. Ze lost ook een ander deel van het probleem op, en het verschil komt precies daar boven waar het ertoe doet.
Direct uitpakken begint met uitpakken voordat de download klaar is, zodat fase drie fase één overlapt in plaats van erop te volgen. Wat het niet doet is fase één schrappen. De archiefvolumes worden nog steeds volledig naar je schijf geschreven, want de uitpakker is een gewone die gewone bestanden leest; direct uitpakken start hem alleen eerder. De twee kopieën bestaan nog steeds, de twee schrijfacties gebeuren nog steeds, en de behoefte aan vrije ruimte is onveranderd.
| de volumes naar schijf schrijven | benodigde vrije ruimte | hoe vaak de inhoud wordt geschreven | |
|---|---|---|---|
| Downloaden, dan uitpakken | ja, daarna teruglezen | ~2× de taak | 2 |
| Direct uitpakken | ja, eerder teruggelezen | ~2× de taak | 2 |
| One-pass | nooit geschreven | ~1× de taak | 1 |
Het tweede verschil is wat er gebeurt als de vorm niet eenvoudig is. Omdat direct uitpakken het werk aan een gewone uitpakker overdraagt naarmate volumes verschijnen, heeft het een ongecompliceerde situatie nodig: de volumes aanwezig in een bruikbare volgorde, geen reparatie in behandeling, niets dat eerst ontgrendeld moet worden, en een archief waarvan de inhoud niet zelf archieven zijn. Zodra daar iets van misgaat, is het verstandige om terug te treden en alsnog aan het eind uit te pakken, en dat is wat er gebeurt. Je krijgt een correcte uitkomst en het gewone tijdsverloop.
Omdat onze uitpakker vanaf het begin rond bytes buiten volgorde is gebouwd, zijn die situaties voor hem geen uitzonderingen. Dat is het werkelijke onderscheid: niet dat wij eerder beginnen, maar dat wij niet leunen op voorwaarden die vaak niet gelden.
Wat het werkelijk overleeft
Zo'n ontwerp is alleen de moeite waard als het geldt voor de posts die je werkelijk tegenkomt, en niet voor een schoon ideaalgeval. De huidige stand: geen enkel containerformaat wordt alleen op schijf afgehandeld. RAR, 7z en zip gaan allemaal via het one-pass-pad.
| vorm | one-pass | opmerkingen |
|---|---|---|
| RAR, opgeslagen (zonder compressie) | ja | het gewone geval bij mediareleases |
| RAR, gecomprimeerd | ja | inclusief een gecomprimeerd archief als buitenste laag |
| RAR 1.5, 3, 4 en 5 | ja | alle vier de generaties van het formaat |
| 7z | ja | inclusief met deflate gecomprimeerde inhoud |
| zip | ja | inclusief bzip2- en LZMA-inhoud |
| Versleutelde inhoud | ja | met een wachtwoord, inclusief versleutelde zip |
| Versleutelde kopteksten | ja | waar ook de bestandsnamen verborgen zijn |
| Wachtwoordketens | ja | het wachtwoord van elke laag verpakt in de laag erboven |
| Geneste archieven | ja | gaandeweg ontnest, tot een instelbare diepte |
| Op meerdere lagen beschadigd | ja | reparatie op elk niveau, nog steeds één keer erdoorheen |
| Numeriek gesplitste sets | ja | splitsingen in de stijl name.001 |
| Zelfuitpakkende archieven | schijfronde | het archief begint niet aan het begin van het bestand |
Verdeelde zip (.z01) | schijfronde | en enkele zeldzamere zip-varianten |
| Hervatte taken | schijfronde | een na een herstart voortgezette taak eindigt op de gewone manier |
De drie weigeringen zijn eerlijke en gedragen zich hetzelfde: de taak wordt correct afgerond, via het gewone pad, en je krijgt voor die download het gewone tijdsverloop met twee kopieën. Er faalt niets; het houdt alleen op snel te zijn op de manier die de rest van deze pagina beschrijft. Zelfuitpakkende archieven worden om een structurele reden geweigerd en niet uit gebrek aan inspanning: een archief herkennen aan zijn eerste bytes kan niet werken wanneer de eerste bytes een programma zijn.
De rijen genest en versleuteld zijn die je serieus moet nemen, want daar geven de meeste clients de taak aan jou terug. Op een gegenereerd corpus van tien geneste vormen, beoordeeld op inhoudshash zodat een client die de inhoud hernoemt toch krediet krijgt, rondden we er 9 van de 10 af zonder ingrijpen; de op één na beste client rondde er 5 af, en twee andere rondden er 2 af. Degene die wij niet automatisch afronden is een ladder van tien niveaus, die netjes eindigt bij de standaard dieptegrens van vijf met de diepste laag als een gezond archief, en volledig doorloopt als je de grens verhoogt. Die runs staan met het volledige raster op de benchmarkpagina.
Waarom het de moeite waard is
Het is sneller, om een weinig glansrijke reden. 60 GB schrijven en teruglezen is zelfs op een snelle SSD niet gratis, en op alles wat trager is is het vaak het werkelijke knelpunt in plaats van het netwerk. Eén schrijfactie en twee leesacties weghalen haalt die tijd volledig van je klok. De winst is het grootst precies waar men het meest merkt: grote taken, en machines waarvan de schijf niet het snelste onderdeel is.
Het halveert de slijtage. SSD's hebben een eindig aantal schrijfacties in zich, en een downloader die elke inhoud twee keer schrijft besteedt dat budget in dubbel tempo zonder dat jij er iets voor terugkrijgt. Over een paar honderd terabyte downloaden, wat voor een actieve gebruiker een gewoon jaar is, is het verschil een merkbaar deel van de levensduur van een schijf.
Het verandert wat past. Vrije ruimte is geen prestatie-eigenschap, het is een ja of nee. Een taak die het dubbele van zijn eigen omvang aan speling nodig heeft draait wel of niet. Ruwweg de omvang van de inhoud nodig hebben betekent dat taken slagen op machines en volumes waar de gewone aanpak eenvoudigweg ophoudt, en daarom past een release van 190 GB hier in ongeveer 157 GB vrije ruimte in plaats van in ongeveer 313 GB.
Het kost minder processortijd. Gegevens niet twee keer door de schijf halen schrapt het werk daarvoor, en verifiëren tijdens de download betekent geen tweede ronde over de inhoud om die te controleren. Onze processorkosten blijven vlak op ongeveer 1.7 processorseconden per gigabyte, van een taak van 35 GB tot een van 190 GB, en dat is de nuttige eigenschap: de kosten per gigabyte groeien niet mee met de taak.
Het draait in minder geheugen, en in begrensd geheugen. Omdat bytes worden verbruikt zodra ze binnenkomen in plaats van opgehoopt, is de werkverzameling een budget dat jij instelt en geen functie van de taakomvang. Dat is wat het mogelijk maakt een release van 190 GB te verwerken op een machine met ruwweg 1.1 GB beschikbaar. Wat telt is niet het getal maar de vorm: geheugen dat meegroeit met de taak komt uiteindelijk een taak tegen die jouw machine niet kan afmaken, en het faalt door wisselbestandgebruik of door te worden afgeschoten in plaats van door het je te vertellen.
Bij elkaar gaat dit minder over het winnen van een benchmark dan over waar de software überhaupt kan draaien. Een ontwerp dat de helft van de vrije ruimte, de helft van de schrijfacties en een begrensde hoeveelheid geheugen nodig heeft werkt op een kleine thuisserver, een oudere laptop of een NAS, en daar leeft een flink deel van dit soort software ook echt.
Elk cijfer op deze pagina is gemeten en gepubliceerd met de build en de datum ernaast op de benchmarkpagina, inclusief de runs die we verliezen. Het eerlijke tegenwicht, daar ook vermeld: een uitpakker en hersteller gebouwd om met een lopende download mee te rijden houden meer geheugen bezet dan een losstaand hulpmiddel dat één keer vanaf de opdrachtregel draait, dus als jouw randvoorwaarde de kleinst mogelijke voetafdruk is voor een eenmalige taak op een bestand dat je al hebt, winnen de gespecialiseerde hulpmiddelen die kolom.