Forklart · én
Det meste av det som gjør denne klienten rask, er ikke en raskere nettverksvei. Det er at dataene bare flytter seg én gang. Dette er hva det betyr i praksis, hvorfor det er noe annet enn direkte utpakking, hvilke arkivformer som overlever det, og hva fjerningen av skriv-og-les-tilbake-runden faktisk er verdt på en ekte maskin.
Utgangspunktet
En post er tusenvis av små kodede artikler som til sammen danner et sett arkivbind, som i sin tur inneholder fila du egentlig vil ha. Å komme fra det ene til det andre har tradisjonelt vært fire atskilte jobber, hver ferdig før den neste begynner.
Hvert trinn er korrekt, og resultatet er riktig. Men innholdet er skrevet to ganger, lest minst to ganger, og på det høyeste måtte disken romme to fullstendige kopier av en jobb du bare ville ha én kopi av. Klokka du opplever, er alle fire trinnene etter hverandre, og derfor kan en klient melde om en rask nedlasting og likevel la deg vente.
Endringen
Én omgang betyr at bytene går fra nettverket til sitt endelige mål uten noen gang å bli en arkivfil på disken din. Det finnes ikke trinn to eller tre, fordi arbeidet i begge skjer mens trinn én fortsatt går.
I praksis blir hver artikkel dekodet i minnet så snart den kommer, og gitt rett videre til to ting samtidig. Verifikatoren sjekker den umiddelbart mot paritetsdataene, så riktigheten blir fastslått mens dataene lander, ikke ved å lese dem om igjen senere. Utpakkeren behandler de innkommende bytene som en posisjon inne i arkivet, regner ut hvilken del av hvilken innholdsfil de hører til, og skriver dem dit.
Arkivbindene blir aldri satt sammen. De finnes som en struktur utpakkeren forstår mens nedlastingen er i lufta, og det eneste som når disken din, er fila du ville ha. Når den siste artikkelen kommer, er det praktisk talt ingenting igjen å gjøre, og derfor ligger slutttidene våre nær selve nedlastingstiden i stedet for en nedlasting pluss en hale.
Den målbare følgen: for den samme jobben skriver vi omtrent halvparten så mye, leser langt mindre tilbake, og trenger omtrent innholdets egen størrelse i ledig plass i stedet for det dobbelte. På en utgivelse på 190 GB er det omkring 157 GB ledig plass mot omkring 313 GB, og omtrent en tredjedel av disktrafikken.
To ting gjør dette vanskeligere enn det høres ut som, og de er grunnen til at det er uvanlig. Artikler kommer ikke i rekkefølge, så utpakkeren må takle byte som lander på vilkårlige posisjoner i stedet for som en strøm fra begynnelsen. Og et komprimert arkiv kan ikke pakkes ut fra midten, så enhver del av arbeidet som virkelig krever rekkefølge, må gjenkjennes og håndteres annerledes framfor å antas bort.
Sammenligningen folk spør om
Direkte utpakking er en god funksjon, og klientene som har den, er bedre stilt med den. Den løser også en annen del av problemet, og forskjellen viser seg akkurat der det betyr noe.
Direkte utpakking begynner å pakke ut før nedlastingen er ferdig, slik at trinn tre overlapper trinn én i stedet for å følge etter. Det den ikke gjør, er å fjerne trinn én. Arkivbindene blir fortsatt skrevet i sin helhet til disken din, for utpakkeren er en vanlig en som leser vanlige filer; direkte utpakking starter den bare tidligere. De to kopiene finnes fortsatt, de to skrivingene skjer fortsatt, og behovet for ledig plass er uendret.
| skrive bindene til disk | nødvendig ledig plass | antall ganger innholdet skrives | |
|---|---|---|---|
| Last ned, pakk så ut | ja, deretter tilbakelesing | ~2× jobben | 2 |
| Direkte utpakking | ja, lest tilbake tidligere | ~2× jobben | 2 |
| Én omgang | skrives aldri | ~1× jobben | 1 |
Den andre forskjellen er hva som skjer når formen ikke er enkel. Fordi direkte utpakking gir arbeidet videre til en vanlig utpakker etter hvert som bindene dukker opp, trenger den at situasjonen er grei: bindene til stede i en brukbar rekkefølge, ingen reparasjon som venter, ingenting som må låses opp først, og et arkiv hvis innhold ikke selv er arkiver. Når noe av det svikter, er det fornuftige å trekke seg og falle tilbake på å pakke ut til slutt, og det er det som skjer. Du får et korrekt resultat og den vanlige tidsbruken.
Fordi utpakkeren vår er bygd rundt byte i uorden fra starten, er de situasjonene ingen unntak for den. Det er den virkelige forskjellen: ikke at vi begynner tidligere, men at vi ikke støtter oss på vilkår som ofte ikke holder.
Hva som faktisk overlever det
En slik konstruksjon er bare verdt å ha hvis den gjelder postene du faktisk møter, og ikke et rent beste tilfelle. Dagens stilling: ingen beholderformat håndteres bare på disk. RAR, 7z og zip går alle gjennom veien med én omgang.
| form | én omgang | merknader |
|---|---|---|
| RAR, lagret (uten komprimering) | ja | det vanlige tilfellet for medieutgivelser |
| RAR, komprimert | ja | inkludert et komprimert arkiv som ytterste lag |
| RAR 1.5, 3, 4 og 5 | ja | alle fire generasjonene av formatet |
| 7z | ja | inkludert deflate-komprimert innhold |
| zip | ja | inkludert bzip2- og LZMA-innhold |
| Kryptert innhold | ja | med passord, inkludert kryptert zip |
| Krypterte hoder | ja | der også filnavnene er skjult |
| Passordkjeder | ja | passordet til hvert lag pakket inn i laget over |
| Nøstede arkiver | ja | løsnøstet underveis, til en innstillbar dybde |
| Skadd i flere lag | ja | reparasjon på hvert nivå, fortsatt én omgang |
| Numerisk delte sett | ja | deling av typen name.001 |
| Selvutpakkende arkiver | diskomgang | arkivet begynner ikke ved starten av fila |
Oppdelt zip (.z01) | diskomgang | og noen sjeldnere zip-varianter |
| Gjenopptatte jobber | diskomgang | en jobb som fortsetter etter en omstart, avsluttes på vanlig vis |
De tre avslagene er ærlige og oppfører seg likt: jobben fullføres korrekt, langs den vanlige veien, og for den nedlastingen får du den vanlige tidsbruken med to kopier. Ingenting svikter; det slutter bare å være raskt på den måten resten av denne siden beskriver. Selvutpakkende arkiver avvises av en strukturell grunn og ikke av mangel på innsats: å kjenne igjen et arkiv på de første bytene kan ikke virke når de første bytene er et program.
Radene nøstet og kryptert er de det er verdt å ta på alvor, for det er der de fleste klienter gir jobben tilbake til deg. På et generert materiale med ti nøstede former, bedømt på innholdshash slik at en klient som gir innholdet nytt navn likevel får det godskrevet, fullførte vi 9 av 10 uten inngrep; den nest beste klienten fullførte 5, og to andre fullførte 2. Den vi ikke fullfører automatisk, er en stige med ti nivåer, som avsluttes pent ved standard dybdegrense på fem med det dypeste laget igjen som et friskt arkiv, og fullføres helt hvis du hever grensen. De omgangene ligger med hele rutenettet på ytelsestestsiden.
Hvorfor det er verdt å gjøre
Det er raskere, av en lite glamorøs grunn. Å skrive 60 GB og lese dem tilbake er ikke gratis selv på en rask SSD, og på noe tregere er det ofte den egentlige flaskehalsen framfor nettverket. Å fjerne én skriving og to lesinger fjerner den tida helt fra klokka di. Gevinsten er størst nettopp der folk merker den mest: store jobber, og maskiner der disken ikke er den raskeste delen.
Det halverer slitasjen. SSD-er har et endelig antall skrivinger i seg, og en nedlaster som skriver hvert innhold to ganger, bruker det budsjettet i dobbelt tempo uten noen nytte for deg. Over et par hundre terabyte nedlasting, som er et vanlig år for en aktiv bruker, er forskjellen en merkbar del av levetiden til en disk.
Det endrer hva som får plass. Ledig plass er ikke en ytelsesegenskap, det er et ja eller nei. En jobb som trenger det dobbelte av sin egen størrelse i slingringsmonn, enten går den eller så går den ikke. Å trenge omtrent innholdets størrelse betyr at jobber blir ferdige på maskiner og volumer der den vanlige framgangsmåten rett og slett stopper, og det er derfor en utgivelse på 190 GB her får plass i omkring 157 GB ledig plass framfor omkring 313 GB.
Det koster mindre prosessortid. Å ikke flytte data gjennom disken to ganger fjerner arbeidet med det, og å verifisere underveis betyr ingen andre omgang over innholdet for å sjekke det. Prosessorkostnaden vår holder seg flat på omkring 1.7 prosessorsekunder per gigabyte, fra en jobb på 35 GB til en på 190 GB, og det er den nyttige egenskapen: kostnaden per gigabyte vokser ikke når jobben gjør det.
Den kjører på mindre minne, og på avgrenset minne. Fordi byte forbrukes etter hvert som de kommer i stedet for å hope seg opp, er arbeidsmengden et budsjett du setter, ikke en funksjon av jobbens størrelse. Det er det som gjør at en utgivelse på 190 GB kan behandles på en maskin med omtrent 1.1 GB tilgjengelig. Det som betyr noe, er ikke tallet, men formen: minne som vokser med jobben, vil før eller siden møte en jobb maskinen din ikke får gjort ferdig, og den svikter ved veksling til disk eller ved å bli drept i stedet for ved å si fra til deg.
Til sammen handler dette mindre om å vinne en ytelsestest enn om hvor programvaren i det hele tatt kan kjøre. En konstruksjon som trenger halvparten av den ledige plassen, halvparten av skrivingene og en avgrenset mengde minne, virker på en liten hjemmetjener, en eldre bærbar eller en NAS, og det er der en god del av denne programvaren faktisk bor.
Hvert tall på denne siden er målt og publisert med bygg og dato ved siden av på ytelsestestsiden, inkludert omgangene vi taper. Den ærlige motvekten, som også står der: en utpakker og reparatør bygd for å følge en pågående nedlasting holder mer minne opptatt enn et frittstående verktøy som kjøres én gang fra kommandolinja, så hvis begrensningen din er minst mulig avtrykk for en engangsjobb på ei fil du allerede har, vinner de spesialiserte verktøyene den kolonnen.