Speichergrenzen des Browsers bei der Dateiverarbeitung
Meine Datei hat nur 15 MB. Warum ist dem Tab der Speicher ausgegangen?
Die Datei auf der Festplatte ist die komprimierte Fassung
Das ganze Missverständnis in einem Satz: Die Zahl, die Sie im Dateimanager sehen, ist die Größe der komprimierten Daten, und in komprimiertem Zustand lässt sich nichts verarbeiten. Um ein Bild zu skalieren, neu zu komprimieren, umzuwandeln oder zu analysieren, muss es zuerst in rohe Pixel decodiert werden – und rohe Pixel sind riesig.
Die Rechnung ist einfach. Ein Pixel im Arbeitsspeicher belegt normalerweise vier Bytes – Rot, Grün, Blau und Alpha. Ein Foto mit 4000 × 3000 Pixeln hat zwölf Millionen Pixel, die decodierte Bitmap ist also rund 48 MB groß. Das JPEG, aus dem es kam, war vielleicht 4 MB groß. Die Datei ist um den Faktor zwölf gewachsen, bevor überhaupt irgendeine Arbeit begonnen hat.
| Abmessungen | Pixel | Decodierte Bitmap |
|---|---|---|
| 1920 × 1080 | 2,1 Millionen | rund 8 MB |
| 4000 × 3000 | 12 Millionen | rund 48 MB |
| 6000 × 4000 | 24 Millionen | rund 96 MB |
| 10000 × 10000 | 100 Millionen | rund 400 MB |
Und mit einer Kopie ist es nie getan
Eine realistische Verarbeitungskette hält mehrere Kopien gleichzeitig vor: die komprimierten Eingabebytes, die decodierte Quell-Bitmap, eine Ausgabe-Bitmap in den neuen Abmessungen, die internen Puffer des Encoders und das komprimierte Ergebnis. Ein Werkzeug, das zusätzlich eine Vorschau zeigt, hält noch eine weitere. Für das Foto mit 4000 × 3000 Pixeln von oben ist ein Spitzenbedarf von zwei- bis dreihundert Megabyte völlig gewöhnlich – bei einer Datei, die nach 4 MB aussah.
Die Rasterung eines PDFs verhält sich genauso, Seite für Seite: Eine mit 300 DPI gerenderte A4-Seite hat rund 2480 × 3508 Pixel, decodiert etwa 35 MB, und ein Werkzeug, das mehrere Seiten gleichzeitig rendert, vervielfacht das. Bei Video ist es noch schlimmer, weil ein Decoder mehrere Referenzbilder gleichzeitig im Speicher halten muss.
Wo die tatsächlichen Obergrenzen liegen
- Das Speicherbudget eines Tabs legt der Browser fest, nicht die Website, und es ist kleiner als der eingebaute Arbeitsspeicher des Rechners. Es schrumpft außerdem, wenn andere Tabs beschäftigt sind.
- WebAssembly-Module, die für das verbreitete 32-Bit-Speichermodell gebaut sind, können höchstens vier Gibibyte adressieren, und Browser erlauben pro Instanz oft deutlich weniger.
- Einzelne Puffer haben eine eigene Maximallänge, die weit unter dem Gesamtspeicher liegt, den eine Seite belegen darf.
- Mobile Betriebssysteme beenden einen Tab, der zu groß wird, ohne Warnung und ohne Fehler, den die Seite abfangen könnte.
- Der Grafikspeicher ist ein eigener, kleinerer Pool. Ein Canvas, der größer ist als die Maximalabmessung der Plattform, scheitert schlicht, egal wie viel Systemspeicher frei ist.
Keine dieser Grenzen wird als eine einzelne Zahl veröffentlicht, die man nachschlagen könnte, denn sie hängen vom Browser, von der Version, vom Gerät und davon ab, was sonst noch läuft. Das ist die eigentliche Schwierigkeit: Ein Werkzeug kann nicht nachfragen, wie viel Speicher es benutzen darf.
Warum Handys der strenge Fall sind
Handys haben weniger physischen Speicher, kein Swap im Sinne eines Desktops und ein Betriebssystem, das ihn Hintergrundprozessen aggressiv wieder abnimmt. Ein Browser-Tab ist in dem Moment ein Hintergrundprozess, in dem Sie eine Nachricht beantworten. Mobile Browser halten deshalb engere Budgets und verwerfen einen Tab schneller, und dieses Verwerfen sieht für Sie meist so aus, als lade die Seite neu und verliere Ihre Arbeit, und nicht wie ein Fehler.
Die praktische Folge ist, dass eine Aufgabe, die auf einem Laptop durchläuft, auf einem Handy mit derselben Datei unmöglich sein kann. Das ist kein Mangel des Werkzeugs. Es ist eine Hardwaregrenze, und die ehrliche Reaktion ist, das vor dem Start zu sagen, statt auf halbem Weg abzustürzen.
Wie sich ein sorgfältiges Werkzeug verhält
- Es schätzt den Speicherbedarf anhand der decodierten Abmessungen ab, bevor es irgendetwas belegt, und lehnt eine Aufgabe ab, die offensichtlich nicht hineinpasst.
- Auf einem knapp bemessenen Gerät verarbeitet es eine Datei nach der anderen, statt einen Stapel parallel laufen zu lassen.
- Es überträgt Puffer zwischen der Seite und ihren Workern, statt sie zu kopieren, damit eine große Datei nicht zweimal existiert.
- Es gibt jedes Ergebnis frei, sobald es geschrieben ist, und zieht die temporären URLs zurück, die die Daten sonst am Leben hielten.
- Wo das Format es erlaubt, arbeitet es Seite für Seite oder Bild für Bild im Stream, statt ein ganzes Dokument in den Speicher zu laden.
- Es deckelt die Pixelanzahl, die es annimmt – und genau das verhindert, dass eine kleine Datei, die sich zu einer riesigen Zeichenfläche aufbläht, den Tab mit in den Abgrund reißt.
Was Sie tun können, wenn eine Aufgabe scheitert
- Schließen Sie andere Tabs. Sie konkurrieren um dasselbe Budget, und Browser teilen es nicht fair auf.
- Verarbeiten Sie weniger Dateien auf einmal. Eine Warteschlange mit genau einem Eintrag ist langsamer und geht weit eher zu Ende.
- Reduzieren Sie zuerst die Abmessungen. Die längste Kante zu halbieren viertelt den Speicherbedarf, und meistens wollten Sie ohnehin genau das.
- Teilen Sie ein großes PDF auf und verarbeiten Sie die Teile.
- Wechseln Sie für die größten Aufgaben an einen Desktop-Rechner. Das ist kein Versagen der lokalen Verarbeitung, sondern der richtige Umgang mit der Hardware, die Sie haben.
- Starten Sie den Browser neu, wenn ein Tab seit Tagen offen ist. Lange offene Tabs sammeln Speicher an, den ein Neuladen wieder freigibt.
Die Grenze jeder Schätzung
Browser geben nur einen groben Hinweis auf den verfügbaren Speicher preis, manche gar keinen. Jede Zahl, die ein lokales Werkzeug Ihnen zeigt, ist daher eine Schätzung aus den Abmessungen der Datei und einem konservativen Modell der Verarbeitungskette und kein Messwert vom Betriebssystem. Sie hilft bei der Entscheidung, ob man eine Aufgabe überhaupt versucht. Sie ist kein Versprechen, dass die Aufgabe durchläuft, denn der ausschlaggebende Faktor – was der Rest des Geräts in den nächsten dreißig Sekunden tut – ist nichts, was eine Webseite sehen kann.
Passende Tools
Quellen
- W3C — WebAssembly Core Specification, memory model
- W3C — Device Memory API, and why the value is coarse
- WHATWG — HTML Standard, transferable objects