[English]Die Google-Entwickler mussten die Speicheroptimierung (RAM-Belegung) für Windows 10 Version 2004, die im Chromium-Browser eingebaut werden sollte, im Entwicklungszweig M85 wieder deaktivieren. Der Grund: Diese Optimierung führte zu Performance-Verlusten zwischen 10 Prozent und 13 Prozent mehr CPU-Leistungsaufnahme.
Anzeige
Der Google Chrome-Browser und alle Chromium-basierenden Browser sind bei den Nutzern als RAM-Fresser bekannt. Das sollte sich eigentlich bald, zumindest für das Windows 10 Mai 2020 Update (Version 2004) ändern.
RAM-Optimierung in Windows 10 2004
Im Rahmen des Projekts Reunion, bei dem Win32-Anwendungen und UWP-Apps für Entwickler zusammen geführt wurden, hat Microsoft auch eine neue Segment Heap-API eingeführt. Anwendungen können diese neue API verwenden, um die Speicherbelegung – im Vergleich mit dem früheren Legacy Heap – zu optimieren und zu reduzieren.
In einem Blog-Beitrag Improving Memory Usage in Microsoft Edge hatte Kim Denny, Microsoft Programm-Manager für Edge, Mitte Juni 2020 einige Details verraten. Beim Chromium-basierenden Edge-Browser führte die neue API dazu, dass der Speicherbedarf des Browsers bei Labortests um bis zu 27% zurückging. Da alles auf dem Chromium-Projekt aufsetzt, gilt die Speicherreduzierung unter Windows 10 Version 2004 für alle Chromium-basierende Browser wie der Google Chrome, den Vivaldi etc., und nicht nur für den Edge-Browser.
Der Preis: Verluste bis zu 13 %
Einem Intel-Ingenieur, der sich das Ganze genauer angeschaut hat, ist dann aber aufgefallen, dass man diese Speicheroptimierung mit einer teilweise drastischen Leistungseinbuße bei der CPU-Performance erkauft hatte. Die Diskussion ist in der Chromium Bug-Liste im Thread Issue 1102281: Performance regression with Windows segment heap nachlesbar. Dort führt der Betreffende aus, dass er bei einem Intel i9-9900K Prozessor folgende Leistungseinbußen bei Benchmarks festgestellt habe:
Anzeige
- Speedometer2.0: ~ -5%
- WebXPRT3: ~-5.8%
- JetStream2: ~-6.2%
Das Ganze ist der Verwendung der neuen Segment Heap-API unter Windows 10 Version 2004 geschuldet. ZDNet hat das Ganze in diesem Artikel aufgegriffen und berichtet von Leistungseinbußen zwischen 10% (Leistungsverlust beim speedometer 2.0 Benchmark) und 13% erhöhter Leistungsaufnahme durch die CPU, die Google in Labortests ermittelt habe.
Chromium-Entwickler ziehen die Reißleine
Den Leuten von Techdows ist dann aufgefallen, dass die Chromium-Entwickler die Funktion zur RAM-Optimierung über die Segment Heap-API unter Windows 10 Version 2004 im Chromium-Entwicklungszweig M85 wieder deaktiviert haben.
Bruce Dawson vom Chromium-Entwicklerteam geht in diesem Post auf einige Details ein. So erwähnt er, dass in der betreffenden Chromium-Build einige Optimierungen enthalten seien, die die Interpretation diverser Testergebnisse – nach der Einführung diverser Maßnahmen – erschweren. Dazu schreibt es:
Obwohl ich aus Labortests ermutigende Dinge über Speichereinsparungen gehört habe, sehe ich keine Möglichkeit, dies aktiviert zu lassen, bis wir saubere Telemetriedaten und Labortests für 20H1 haben, was beides nicht rechtzeitig für M85 geschehen wird.
Es ist also geplant, dies für M85 abzuschalten (wodurch wir einen weiteren Telemetriedatenpunkt erhalten) und dies in Zukunft überdenken können.
Die Speicheroptimierung ist also nicht für alle Zeiten vom Tisch – aber die Auswirkungen sind so gewaltig, dass die Chromium-Entwickler jetzt die Notbremse ziehen mussten.
Microsoft will nachbessern
Ein Microsoft Edge-Entwickler weist in dem oben erwähnten Post darauf hin, dass es gängige Praxis sei, eine Ressource gegen eine andere zu tauschen. Häufiger sei es erhöhter Speicherverbrauch, einhergehend mit reduzierter CPU-Nutzung, der als Optimierungskriterium gewählt werde. In diesem Fall hat die Reduzierung des Speicherverbrauchs halt eine erhöhte CPU-Leistung zur Folge.
Die Microsoft-Entwickler sehen kurzfristig in der Deaktivierung der Funktion im M85-Entwicklungszweig 'einen guten Kompromiss' und untersuchen, ob die Leistung des Segmentheaps verbessert werden kann. Eine Reduzierung der "Segment Heap"-API bedingten CPU-Leistungszunahme würde laut Microsoft aber "erhebliche Änderungen in der gesamten Codebasis des Browsers" erfordern. Die Chancen stehen also gut, dass die Funktion zur Speicheroptimierung irgendwann wieder in die Chromium-Browser zurück kommt.
Anzeige
"…Ein Microsoft Edge-Entwickler weist in dem oben erwähnten Post darauf hin, dass es gängige Praxis sei, eine Ressource gegen eine andere zu tauschen. Häufiger sei es erhöhter Speicherverbrauch, einhergehend mit reduzierter CPU-Nutzung, der als Optimierungskriterium gewählt werde…"
Dann wäre es aber gut, wenn man wählen könnte! Ausgeschaltet, Speicherreduziert/CPUerhöht und Speichererhöht/CPUreduziert. Dann kann jeder selbst entscheiden, was er will.
Jeder Schalter verdoppelt die Testkomplexität (jedenfalls wenn QA genmacht wird…): denn man mus alles andere einmal "mit" und einmal "ohne" testen. Zudem müssen dann auf Dauer zwei Codepfade gepflegt werden, was irgendwann auch wieder zu Sicherheitslücken führt, weil den einen Pfad kaum jemand nutzt – und deshalb auch nicht anschaut.
Mir sind sinnvolle(!) Voreinstellungen lieber. Vorzugsweise solche, die über anständig durchgeführte Tests mit Anwendern ermittelt wurden. "Wir erstellen aus Telemetriedaten hübsche(?) Powerpoints" reicht dazu allerdings nicht aus…