Minnegrenser i nettleseren når du behandler filer
Filen min er bare 15 MB. Hvorfor gikk fanen tom for minne?
Filen på disken er den komprimerte versjonen
Hele misforståelsen ligger i én setning: tallet du ser i filbehandleren, er størrelsen på de komprimerte dataene, og ingenting kan behandles mens det er komprimert. For å skalere, komprimere på nytt, konvertere eller analysere et bilde må det først dekodes til rå piksler, og rå piksler er enorme.
Regnestykket er enkelt. En piksel i minnet er normalt fire byte – rød, grønn, blå og alfa. Et fotografi på 4000 × 3000 er tolv millioner piksler, så den dekodede bitmapen er omtrent 48 MB. JPEG-en den kom fra, kan ha vært 4 MB. Filen vokste med en faktor på tolv før noe arbeid i det hele tatt begynte.
| Dimensjoner | Piksler | Dekodet bitmap |
|---|---|---|
| 1920 × 1080 | 2,1 millioner | omtrent 8 MB |
| 4000 × 3000 | 12 millioner | omtrent 48 MB |
| 6000 × 4000 | 24 millioner | omtrent 96 MB |
| 10000 × 10000 | 100 millioner | omtrent 400 MB |
Og én kopi er aldri nok
En realistisk arbeidskjede holder flere kopier samtidig: de komprimerte inndatabytene, den dekodede kildebitmapen, en utdatabitmap i de nye dimensjonene, koderens interne buffere og det komprimerte resultatet. Et verktøy som også viser deg en forhåndsvisning, holder enda en. For fotografiet på 4000 × 3000 over er et toppforbruk på to til tre hundre megabyte helt vanlig, for en fil som så ut som 4 MB.
PDF-rasterisering oppfører seg på samme måte, side for side: en A4-side gjengitt ved 300 DPI er omtrent 2480 × 3508 piksler, rundt 35 MB dekodet, og et verktøy som gjengir flere sider samtidig, multipliserer det. Video er enda verre, fordi en dekoder trenger flere referansebilder i minnet samtidig.
Hvor de faktiske takene ligger
- En fanes minnebudsjett settes av nettleseren, ikke av nettstedet, og det er mindre enn minnet maskinen har installert. Det krymper også når andre faner er travle.
- WebAssembly-moduler bygget for den vanlige 32-bits minnemodellen kan adressere høyst fire gibibyte, og nettlesere tillater ofte betydelig mindre enn det per instans.
- Enkeltbuffere har sin egen maksimale lengde, som ligger godt under det totale minnet en side kan bruke.
- Mobile operativsystemer avslutter en fane som blir for stor, uten varsel og uten en feil siden kan fange opp.
- Grafikkminne er et eget, mindre lager. En Canvas som er større enn plattformens maksimale dimensjon, feiler rett og slett, uansett hvor mye systemminne som er ledig.
Ingen av disse er publisert som ett tall du kan slå opp, for de avhenger av nettleseren, versjonen, enheten og hva annet som kjører. Det er den reelle vanskeligheten: et verktøy kan ikke spørre hvor mye minne det får lov til å bruke.
Hvorfor mobiler er det strenge tilfellet
Mobiler har mindre fysisk minne, ingen veksling i den forstand PC-er har, og et operativsystem som er aggressivt med å ta minne tilbake fra bakgrunnsprosesser. En nettleserfane er en bakgrunnsprosess i det øyeblikket du svarer på en melding. Mobilnettlesere holder derfor strammere budsjetter og er raskere til å forkaste en fane, og forkastingen ser for deg vanligvis ut som at siden lastes på nytt og arbeidet ditt forsvinner, ikke som en feilmelding.
Den praktiske konsekvensen er at en jobb som fullfører på en bærbar PC, kan være umulig på en mobil med samme fil. Det er ikke en feil i verktøyet. Det er en maskinvaregrense, og det ærlige svaret er å si det før man starter, i stedet for å krasje halvveis.
Slik oppfører et omhyggelig verktøy seg
- Det anslår minnebruken ut fra de dekodede dimensjonene før det allokerer noe, og avviser en jobb som åpenbart ikke får plass.
- Det behandler én fil om gangen på en begrenset enhet i stedet for å kjøre en bunke i parallell.
- Det overfører buffere mellom siden og workerne sine i stedet for å kopiere dem, slik at en stor fil ikke finnes to ganger.
- Det frigjør hvert resultat så snart det er skrevet, og trekker tilbake de midlertidige URL-ene som ellers ville holdt dataene i live.
- Det strømmer side for side eller bilde for bilde der formatet tillater det, i stedet for å laste et helt dokument inn i minnet.
- Det setter et tak på antall piksler det tar imot, og det er også det som hindrer at en liten fil som utvider seg til en enorm bildeflate, tar knekken på fanen.
Hva du kan gjøre når en jobb feiler
- Lukk andre faner. De konkurrerer om det samme budsjettet, og nettlesere deler det ikke rettferdig.
- Behandle færre filer om gangen. En kø på én er tregere og langt mer sannsynlig å bli ferdig.
- Reduser dimensjonene først. Å halvere den lengste siden firedeler minnebruken, og det er ofte det du ville uansett.
- Del opp en stor PDF og behandle delene.
- Gå over til en stasjonær maskin for de største jobbene. Det er ikke et nederlag for lokal behandling; det er riktig bruk av maskinvaren du har.
- Start nettleseren på nytt hvis en fane har stått åpen i dagevis. Faner med langt liv samler opp minne som en ny innlasting frigjør.
Grensen for ethvert anslag
Nettlesere eksponerer bare et grovt hint om tilgjengelig minne, og noen eksponerer ingenting i det hele tatt. Ethvert tall et lokalt verktøy viser deg, er derfor et anslag bygget på filens egne dimensjoner og en konservativ modell av arbeidskjeden, ikke en avlesning fra operativsystemet. Det er nyttig for å avgjøre om man skal forsøke en jobb. Det er ikke et løfte om at jobben blir fullført, fordi den avgjørende faktoren – hva resten av enheten gjør i løpet av de neste tretti sekundene – er noe en nettside ikke kan se.
Verktøy for dette
Kilder
- W3C — WebAssembly Core Specification, memory model
- W3C — Device Memory API, and why the value is coarse
- WHATWG — HTML Standard, transferable objects