Google schakelt SegmentHeap in Chrome uit vanwege prestatieregressie

In mei heeft Microsoft de Windows 10 May 2020 Update voor Windows 10-gebruikers uitgebracht. De nieuwe update kwam met SegmentHeap waarmee Win32-apps het RAM-gebruik konden verbeteren. Kort na de release kondigde Microsoft aan dat het erin was geslaagd het RAM-gebruik op Edge te verminderen met behulp van de nieuwe functie.

In juni sprong Google ook op de kar en aangekondigd het zal SegmentHeap gebruiken in het Chrome-manifest dat het geheugenverslindende gedrag van Chrome zal oplossen. De functie was later ingeschakeld in Chrome v85, maar na verdere tests is Google doorgegaan en heeft de functie in Chrome uitgeschakeld. Google bekend dat de functie prestatieproblemen veroorzaakte en daarom is uitgeschakeld.

Met commit https://chromium-review.googlesource.com/c/chromium/src/+/2163163 geland, zal Windows >= 10.0.19041.0 (Windows 10 versie 2004 en later) ervoor kiezen chrome.exe te gebruiken voor het gebruik van de segment heap van de erfenishoop. Maar wat leidde tot prestatieregressie voor WebXPRT3, Speedometer2 en JetStream2.

Microsoft daarentegen bekend dat het gebruikelijk is dat een app de ene bron inruilt voor een andere, dus het verminderde geheugengebruik betekende een toename van het CPU-gebruik. Microsoft zei verder dat er enkele verbeteringen kunnen worden aangebracht om de impact te verminderen.

Het is gebruikelijk om de ene grondstof voor de andere te ruilen. Vaker is het meer geheugengebruik voor minder CPU-gebruik. In dit geval is het een verhoogd CPU-gebruik voor een drastisch verminderd geheugengebruik, of nauwkeuriger vast te leggen. Als je had gekeken naar de commit die Bruce maakte, zou je de bug hebben gevonden die hem ertoe bracht de segmentheap te gebruiken, en dat was 100% overhead door het gebruik van de lage fragmentatieheap in browserprocessen.

https://bugs.chromium.org/p/chromium/issues/detail?id=1014701#c9

Dat gezegd hebbende, is er enige verbetering die kan worden gedaan om de impact te verminderen. Ze vallen in twee gebieden, maar geen van beide is gemakkelijk.

1) Verminder de hoeveelheid tijdelijke heaptoewijzingen die de browser maakt. Dit vereist aanzienlijke wijzigingen in de hele codebasis van de browser.
2) Verbeter de prestaties van de Segment-heap zelf. Dit kan alleen worden aangepakt door het Windows-team en we onderzoeken onze opties.

Op de korte termijn is dit een goede afweging van de ene bron voor de andere, aangezien geheugen/commit-gebruik een belangrijk pijnpunt is voor browsergebruikers.

Helaas, gisteravond Google beslist om door te gaan en SegmentHeap uit te schakelen. Het is achter een GN-vlag geplaatst, zodat het team kan blijven experimenteren met de functie, dus het is niet het einde van de weg.

Schakel de segmenthoop standaard uit en voeg een GN-vlag toe om deze te besturen.

Er is enige bezorgdheid dat de kosten van de Segment-heap de kosten niet rechtvaardigen (zie crbug.com/1102281). Deze CL schakelt het standaard uit en plaatst deze functie achter een GN-vlag zodat we ermee kunnen blijven experimenteren.

Via: Techdows