Förklarat · ett
Det mesta av det som gör den här klienten snabb är inte en snabbare nätverksväg. Det är att datan bara flyttas en gång. Det här är vad det betyder i praktiken, varför det är något annat än direkt uppackning, vilka arkivformer som klarar sig igenom, och vad borttagandet av skriv-och-läs-tillbaka-varvet faktiskt är värt på en riktig maskin.
Utgångspunkten
En post är tusentals små kodade artiklar som tillsammans bildar en uppsättning arkivvolymer, vilka i sin tur innehåller den fil du faktiskt vill ha. Att ta sig från det ena till det andra har traditionellt varit fyra separata jobb, vart och ett avslutat innan nästa börjar.
Varje steg är korrekt, och resultatet blir rätt. Men innehållet har skrivits två gånger, lästs minst två gånger, och som mest behövde disken rymma två fullständiga kopior av ett jobb du bara ville ha en kopia av. Klockan du upplever är alla fyra stegen i följd, och därför kan en klient rapportera en snabb nedladdning och ändå låta dig vänta.
Förändringen
Ett enda pass betyder att byten går från nätverket till sin slutdestination utan att någonsin bli en arkivfil på din disk. Det finns inget steg två eller tre, eftersom arbetet i båda sker medan steg ett fortfarande pågår.
I praktiken avkodas varje artikel i minnet så snart den kommer och lämnas direkt till två saker samtidigt. Verifieraren kontrollerar den omedelbart mot paritetsdatan, så riktigheten fastställs när datan landar i stället för genom att läsa om den senare. Uppackaren behandlar de inkommande byten som en position inne i arkivet, räknar ut vilken del av vilken innehållsfil de hör till, och skriver dem där.
Arkivvolymerna sätts aldrig samman. De finns som en struktur uppackaren förstår medan nedladdningen är i luften, och det enda som når din disk är filen du ville ha. När sista artikeln kommer återstår i stort sett ingenting, vilket är varför våra sluttider ligger nära själva nedladdningstiden i stället för en nedladdning plus en svans.
Den mätbara följden: för samma jobb skriver vi ungefär hälften så mycket, läser tillbaka långt mindre, och behöver ungefär innehållets egen storlek i ledigt utrymme i stället för dubbelt. På en utgåva på 190 GB är det omkring 157 GB ledigt mot omkring 313 GB, och ungefär en tredjedel av disktrafiken.
Två saker gör det här svårare än det låter, och de är skälet till att det är ovanligt. Artiklar kommer inte i ordning, så uppackaren måste hantera byte som landar på godtyckliga positioner i stället för som en ström från början. Och ett komprimerat arkiv kan inte packas upp från mitten, så varje del av arbetet som verkligen kräver ordning måste kännas igen och hanteras annorlunda i stället för antas bort.
Jämförelsen folk frågar om
Direkt uppackning är en bra funktion och de klienter som har den är bättre för det. Den löser också en annan del av problemet, och skillnaden visar sig precis där det spelar roll.
Direkt uppackning börjar packa upp innan nedladdningen är klar, så att steg tre överlappar steg ett i stället för att följa på det. Vad den inte gör är att ta bort steg ett. Arkivvolymerna skrivs fortfarande i sin helhet till din disk, eftersom uppackaren är en vanlig som läser vanliga filer; direkt uppackning startar den bara tidigare. De två kopiorna finns fortfarande, de två skrivningarna sker fortfarande, och behovet av ledigt utrymme är oförändrat.
| skriva volymerna till disk | ledigt utrymme som krävs | antal gånger innehållet skrivs | |
|---|---|---|---|
| Ladda ned, packa sedan upp | ja, sedan tillbakaläsning | ~2× jobbet | 2 |
| Direkt uppackning | ja, tillbakaläst tidigare | ~2× jobbet | 2 |
| Ett enda pass | skrivs aldrig | ~1× jobbet | 1 |
Den andra skillnaden är vad som händer när formen inte är enkel. Eftersom direkt uppackning lämnar över arbetet till en vanlig uppackare allteftersom volymer dyker upp, behöver den att läget är okomplicerat: volymerna på plats i en användbar ordning, ingen reparation som väntar, inget som måste låsas upp först, och ett arkiv vars innehåll inte självt är arkiv. När något av det brister är det förnuftiga att dra sig tillbaka och falla tillbaka på uppackning i slutet, och det är vad som sker. Du får ett korrekt resultat och den vanliga tidsåtgången.
Eftersom vår uppackare är byggd kring byte i oordning från början är de lägena inga undantag för den. Det är den verkliga skillnaden: inte att vi börjar tidigare, utan att vi inte förlitar oss på villkor som ofta inte gäller.
Vad som faktiskt klarar sig igenom
En sådan konstruktion är bara värd att ha om den gäller de poster du faktiskt stöter på, och inte ett rent bästafall. Nuvarande läge: inget behållarformat hanteras enbart på disk. RAR, 7z och zip går alla genom vägen med ett enda pass.
| form | ett enda pass | anmärkningar |
|---|---|---|
| RAR, lagrad (utan komprimering) | ja | det vanliga fallet för medieutgåvor |
| RAR, komprimerad | ja | inklusive ett komprimerat arkiv som yttersta lager |
| RAR 1.5, 3, 4 och 5 | ja | alla fyra generationer av formatet |
| 7z | ja | inklusive deflate-komprimerat innehåll |
| zip | ja | inklusive bzip2- och LZMA-innehåll |
| Krypterat innehåll | ja | med lösenord, inklusive krypterad zip |
| Krypterade huvuden | ja | där även filnamnen är dolda |
| Lösenordskedjor | ja | varje lagers lösenord förpackat i lagret ovanför |
| Nästlade arkiv | ja | onästlade i farten, till ett inställbart djup |
| Skadat i flera lager | ja | reparation på varje nivå, fortfarande ett pass |
| Numeriskt delade uppsättningar | ja | delningar av typen name.001 |
| Självuppackande arkiv | diskpass | arkivet börjar inte vid filens början |
Uppdelad zip (.z01) | diskpass | och några ovanligare zip-varianter |
| Återupptagna jobb | diskpass | ett jobb som fortsätter efter en omstart avslutas på vanligt sätt |
De tre avslagen är ärliga och beter sig likadant: jobbet slutförs korrekt, via den vanliga vägen, och du får den vanliga tidsåtgången med två kopior för den nedladdningen. Ingenting misslyckas; det slutar bara vara snabbt på det sätt resten av sidan beskriver. Självuppackande arkiv avvisas av ett strukturellt skäl och inte av bristande ansträngning: att känna igen ett arkiv på dess första byte kan inte fungera när de första byten är ett program.
Raderna nästlat och krypterat är de som är värda att ta på allvar, för det är där de flesta klienter lämnar tillbaka jobbet till dig. På ett genererat underlag med tio nästlade former, bedömt på innehållshash så att en klient som byter namn på innehållet ändå får tillgodoräkna sig det, slutförde vi 9 av 10 utan ingripande; den näst bästa klienten slutförde 5, och två andra slutförde 2. Den vi inte slutför automatiskt är en stege med tio nivåer, som avslutas rent vid standarddjupgränsen fem med det djupaste lagret kvar som ett friskt arkiv, och slutförs helt om du höjer gränsen. De omgångarna finns med hela rutnätet på benchmarksidan.
Varför det är värt att göra
Det är snabbare, av ett oglamoröst skäl. Att skriva 60 GB och läsa tillbaka dem är inte gratis ens på en snabb solid state-disk, och på något långsammare är det ofta den verkliga flaskhalsen snarare än nätverket. Att ta bort en skrivning och två läsningar tar bort den tiden helt från din klocka. Vinsten är störst precis där folk märker den mest: stora jobb, och maskiner vars disk inte är deras snabbaste del.
Det halverar slitaget. Solid state-diskar har ett ändligt antal skrivningar i sig, och en nedladdare som skriver varje innehåll två gånger förbrukar den budgeten i dubbel takt utan någon nytta för dig. Över några hundra terabyte nedladdning, vilket är ett vanligt år för en aktiv användare, är skillnaden en märkbar del av en disks livslängd.
Det ändrar vad som får plats. Ledigt utrymme är inte en prestandaegenskap, det är ett ja eller nej. Ett jobb som behöver dubbla sin egen storlek i marginal antingen går eller går inte. Att behöva ungefär innehållets storlek betyder att jobb blir klara på maskiner och volymer där det vanliga tillvägagångssättet helt enkelt tar stopp, och det är därför en utgåva på 190 GB ryms här i omkring 157 GB ledigt i stället för omkring 313 GB.
Det kostar mindre processortid. Att inte flytta data genom disken två gånger tar bort arbetet med det, och att verifiera under nedladdningen betyder inget andra pass över innehållet för att kontrollera det. Vår processorkostnad håller sig platt kring 1.7 processorsekunder per gigabyte, från ett jobb på 35 GB till ett på 190 GB, och det är den nyttiga egenskapen: kostnaden per gigabyte växer inte när jobbet gör det.
Det körs i mindre minne, och i begränsat minne. Eftersom byten förbrukas när de kommer i stället för att samlas på hög är arbetsmängden en budget du sätter och inte en funktion av jobbets storlek. Det är vad som gör att en utgåva på 190 GB kan bearbetas på en maskin med ungefär 1.1 GB tillgängligt. Det som betyder något är inte talet utan formen: minne som växer med jobbet kommer förr eller senare att möta ett jobb din maskin inte kan slutföra, och det havererar genom växling till disk eller genom att dödas i stället för genom att berätta det för dig.
Sammantaget handlar detta mindre om att vinna en mätning än om var programvaran över huvud taget kan köras. En konstruktion som behöver hälften av det lediga utrymmet, hälften av skrivningarna och en begränsad mängd minne fungerar på en liten hemmaserver, en äldre bärbar dator eller en NAS, och det är där en god del av den här sortens programvara faktiskt bor.
Varje siffra på den här sidan är uppmätt och publicerad med bygge och datum bredvid sig på benchmarksidan, inklusive de omgångar vi förlorar. Den ärliga motvikten, som också står där: en uppackare och reparerare byggda för att följa med en pågående nedladdning håller mer minne i anspråk än ett fristående verktyg som körs en gång från kommandoraden, så om din begränsning är minsta möjliga avtryck för ett engångsjobb på en fil du redan har, vinner de specialiserade verktygen den kolumnen.