Forklaret · et
Det meste af det, der gør denne klient hurtig, er ikke en hurtigere netværksvej. Det er, at data kun flytter sig én gang. Det er hvad det betyder i praksis, hvorfor det er noget andet end direkte udpakning, hvilke arkivformer der overlever det, og hvad fjernelsen af skriv-og-læs-tilbage-runden faktisk er værd på en rigtig maskine.
Udgangspunktet
Et opslag er tusindvis af små kodede artikler, der tilsammen danner et sæt arkivbind, som til gengæld indeholder den fil, du faktisk vil have. At komme fra det ene til det andet har traditionelt været fire adskilte opgaver, hver færdig før den næste begynder.
Hvert trin er korrekt, og resultatet er rigtigt. Men indholdet er blevet skrevet to gange, læst mindst to gange, og på det højeste punkt måtte disken rumme to komplette kopier af en opgave, du kun ville have én kopi af. Uret, du oplever, er alle fire trin i rækkefølge, og derfor kan en klient melde om et hurtigt download og alligevel lade dig vente.
Ændringen
Ét gennemløb betyder, at byte går fra netværket til deres endelige bestemmelsessted uden nogensinde at blive en arkivfil på din disk. Der findes ikke trin to eller tre, fordi arbejdet i begge sker, mens trin ét stadig kører.
I praksis bliver hver artikel afkodet i hukommelsen, så snart den ankommer, og givet videre til to ting på én gang. Verifikatoren tjekker den øjeblikkeligt mod paritetsdataene, så rigtigheden er fastslået, mens data lander, i stedet for ved at læse dem igen senere. Udpakkeren behandler de indkommende byte som en position inde i arkivet, regner ud hvilken del af hvilken indholdsfil de hører til, og skriver dem der.
Arkivbindene bliver aldrig samlet. De findes som en struktur, udpakkeren forstår, mens downloadet er i luften, og det eneste, der når din disk, er den fil, du ville have. Når den sidste artikel ankommer, er der stort set intet tilbage at gøre, og derfor ligger vores sluttider tæt på selve downloadtiden i stedet for et download plus en hale.
Den målbare følge: for den samme opgave skriver vi omtrent halvt så meget, læser langt mindre tilbage, og har brug for omtrent indholdets egen størrelse i ledig plads i stedet for det dobbelte. På en udgivelse på 190 GB er det omkring 157 GB ledig plads mod omkring 313 GB, og omtrent en tredjedel af disktrafikken.
To ting gør dette sværere, end det lyder, og de er grunden til, at det er ualmindeligt. Artikler ankommer ikke i rækkefølge, så udpakkeren skal kunne håndtere byte, der lander på vilkårlige positioner, i stedet for som en strøm fra begyndelsen. Og et komprimeret arkiv kan ikke pakkes ud fra midten, så enhver del af arbejdet, der virkelig kræver rækkefølge, skal genkendes og behandles anderledes i stedet for antages væk.
Sammenligningen folk spørger om
Direkte udpakning er en god funktion, og de klienter, der har den, er bedre stillet med den. Den løser også en anden del af problemet, og forskellen viser sig præcis dér, hvor det betyder noget.
Direkte udpakning begynder at pakke ud, før downloadet er færdigt, så trin tre overlapper trin ét i stedet for at følge efter det. Hvad den ikke gør, er at fjerne trin ét. Arkivbindene bliver stadig skrevet i deres fulde længde til din disk, for udpakkeren er en almindelig, der læser almindelige filer; direkte udpakning starter den blot tidligere. De to kopier findes stadig, de to skrivninger sker stadig, og behovet for ledig plads er uændret.
| skrive bindene til disk | nødvendig ledig plads | antal gange indholdet skrives | |
|---|---|---|---|
| Hent, og pak så ud | ja, derefter tilbagelæsning | ~2× opgaven | 2 |
| Direkte udpakning | ja, læst tilbage tidligere | ~2× opgaven | 2 |
| Ét gennemløb | skrives aldrig | ~1× opgaven | 1 |
Den anden forskel er, hvad der sker, når formen ikke er enkel. Fordi direkte udpakning giver arbejdet videre til en almindelig udpakker, efterhånden som bindene dukker op, kræver den, at situationen er ligetil: bindene til stede i en brugbar rækkefølge, ingen reparation undervejs, intet der først skal låses op, og et arkiv, hvis indhold ikke selv er arkiver. Når noget af det svigter, er det fornuftige at trække sig og falde tilbage på at pakke ud til sidst, og det er, hvad der sker. Du får et korrekt resultat og den sædvanlige tidsforbrug.
Fordi vores udpakker fra begyndelsen er bygget omkring byte i uorden, er de situationer ingen undtagelser for den. Det er den virkelige forskel: ikke at vi begynder tidligere, men at vi ikke læner os op ad betingelser, der ofte ikke holder.
Hvad der faktisk overlever det
Et design som dette er kun værd at have, hvis det gælder de opslag, du faktisk møder, og ikke et pænt bedstetilfælde. Den nuværende stilling: intet beholderformat håndteres kun på disk. RAR, 7z og zip går alle gennem vejen med ét gennemløb.
| form | ét gennemløb | bemærkninger |
|---|---|---|
| RAR, gemt (uden komprimering) | ja | det almindelige tilfælde ved medieudgivelser |
| RAR, komprimeret | ja | inklusive et komprimeret arkiv som yderste lag |
| RAR 1.5, 3, 4 og 5 | ja | alle fire generationer af formatet |
| 7z | ja | inklusive deflate-komprimeret indhold |
| zip | ja | inklusive bzip2- og LZMA-indhold |
| Krypteret indhold | ja | med adgangskode, inklusive krypteret zip |
| Krypterede hoveder | ja | hvor også filnavnene er skjult |
| Adgangskodekæder | ja | hvert lags adgangskode pakket ind i laget ovenover |
| Indlejrede arkiver | ja | udlejret undervejs, til en indstillelig dybde |
| Beskadiget i flere lag | ja | reparation på hvert niveau, stadig ét gennemløb |
| Numerisk delte sæt | ja | opdelinger i stil med name.001 |
| Selvudpakkende arkiver | diskgennemløb | arkivet begynder ikke ved filens start |
Opdelt zip (.z01) | diskgennemløb | og nogle sjældnere zip-varianter |
| Genoptagne opgaver | diskgennemløb | en opgave, der fortsættes efter en genstart, slutter på sædvanlig vis |
De tre afslag er ærlige og opfører sig ens: opgaven fuldføres korrekt ad den sædvanlige vej, og du får det sædvanlige tidsforløb med to kopier for det download. Intet fejler; det holder blot op med at være hurtigt på den måde, resten af siden beskriver. Selvudpakkende arkiver afvises af en strukturel grund og ikke af mangel på indsats: at kende et arkiv på dets første byte kan ikke fungere, når de første byte er et program.
Rækkerne indlejret og krypteret er dem, der er værd at tage alvorligt, for det er dér, de fleste klienter giver opgaven tilbage til dig. På et genereret materiale med ti indlejrede former, bedømt på indholdshash så en klient, der omdøber indholdet, alligevel får det godskrevet, fuldførte vi 9 ud af 10 uden indgriben; den næstbedste klient fuldførte 5, og to andre fuldførte 2. Den, vi ikke fuldfører automatisk, er en stige med ti niveauer, som slutter pænt ved standarddybdegrænsen på fem med det dybeste lag efterladt som et sundt arkiv, og fuldfører helt, hvis du hæver grænsen. De omgange står med hele skemaet på benchmarksiden.
Hvorfor det er værd at gøre
Det er hurtigere, af en uglamourøs grund. At skrive 60 GB og læse dem tilbage er ikke gratis selv på en hurtig SSD, og på noget langsommere er det ofte den egentlige flaskehals frem for netværket. At fjerne én skrivning og to læsninger fjerner den tid helt fra dit ur. Gevinsten er størst netop dér, hvor folk mærker det mest: store opgaver, og maskiner hvis disk ikke er deres hurtigste del.
Det halverer slitagen. SSD'er har et endeligt antal skrivninger i sig, og en downloader, der skriver hvert indhold to gange, bruger det budget i dobbelt tempo uden nogen gevinst for dig. Over et par hundrede terabyte download, hvilket er et almindeligt år for en aktiv bruger, er forskellen en mærkbar del af en disks levetid.
Det ændrer, hvad der kan være. Ledig plads er ikke en ydelsesegenskab, det er et ja eller nej. En opgave, der kræver det dobbelte af sin egen størrelse i luft, kører enten eller gør ikke. At have brug for omtrent indholdets størrelse betyder, at opgaver bliver færdige på maskiner og diske, hvor den sædvanlige fremgangsmåde simpelthen standser, og det er derfor, en udgivelse på 190 GB her kan være i omkring 157 GB ledig plads frem for omkring 313 GB.
Det koster mindre processortid. Ikke at flytte data gennem disken to gange fjerner arbejdet ved det, og at verificere undervejs betyder intet andet gennemløb over indholdet for at tjekke det. Vores processoromkostning holder sig fladt omkring 1.7 processorsekunder pr. gigabyte, fra en opgave på 35 GB til en på 190 GB, og det er den nyttige egenskab: omkostningen pr. gigabyte vokser ikke, når opgaven gør det.
Det kører i mindre hukommelse, og i afgrænset hukommelse. Fordi byte forbruges, efterhånden som de ankommer, i stedet for at hobe sig op, er arbejdsmængden et budget, du sætter, og ikke en funktion af opgavens størrelse. Det er, hvad der gør det muligt at behandle en udgivelse på 190 GB på en maskine med omtrent 1.1 GB til rådighed. Det, der betyder noget, er ikke tallet, men formen: hukommelse, der vokser med opgaven, møder før eller siden en opgave, din maskine ikke kan gøre færdig, og den svigter ved at swappe eller blive dræbt i stedet for ved at fortælle dig det.
Tilsammen handler dette mindre om at vinde en måling end om, hvor softwaren overhovedet kan køre. Et design, der har brug for halvdelen af den ledige plads, halvdelen af skrivningerne og en afgrænset mængde hukommelse, virker på en lille hjemmeserver, en ældre bærbar eller en NAS, og det er dér, en god del af denne software faktisk bor.
Hvert tal på denne side er målt og offentliggjort med build og dato ved siden af på benchmarksiden, inklusive de omgange, vi taber. Den ærlige modvægt, som også står der: en udpakker og reparatør bygget til at følge et igangværende download holder mere hukommelse besat end et selvstændigt værktøj, der køres én gang fra kommandolinjen, så hvis din begrænsning er det mindst mulige fodaftryk til en engangsopgave på en fil, du allerede har, vinder de dedikerede værktøjer den kolonne.