Google deaktiverer SegmentHeap på Chrome på grund af præstationsregression
3 min. Læs
Udgivet den
Del denne artikel
Forbedre denne vejledning
Læs vores oplysningsside for at finde ud af, hvordan du kan hjælpe MSPoweruser med at opretholde redaktionen Læs mere
I maj udgav Microsoft Windows 10 May 2020 Update til Windows 10-brugere. Den nye opdatering kom med SegmentHeap, der gjorde det muligt for Win32-apps at forbedre RAM-forbruget. Kort efter udgivelsen meddelte Microsoft, at det var lykkedes at reducere RAM-forbruget på Edge ved hjælp af den nye funktion.
I juni hoppede Google også med på vognen og annoncerede det vil bruge SegmentHeap i Chromes manifest, som vil rette op på Chromes hukommelsessvigende adfærd. Indslaget var senere aktiveret i Chrome v85, men efter yderligere test er Google gået videre og deaktiveret funktionen på Chrome. Google bemærkede at funktionen forårsagede ydeevneproblemer, og at den derfor er blevet deaktiveret.
Med commit https://chromium-review.googlesource.com/c/chromium/src/+/2163163 landet, vil Windows >= 10.0.19041.0 (Windows 10 version 2004 og nyere) vælge chrome.exe til at bruge segmentheapen i stedet for af arvebunken. Men som førte til præstationsregression for WebXPRT3, Speedometer2 og JetStream2.
Microsoft på den anden side, bemærkede at det er almindeligt for en app at bytte en ressource ud med en anden, så det reducerede hukommelsesforbrug betød en stigning i CPU-forbruget. Microsoft sagde endvidere, at der kunne gøres nogle forbedringer for at reducere virkningen.
Det er almindelig praksis at bytte en ressource ud med en anden. Oftere er det øget hukommelsesforbrug for reduceret CPU-brug. I dette tilfælde er det øget CPU-brug for dramatisk reduceret hukommelsesforbrug, eller mere præcist commit. Hvis du kiggede på den commit, Bruce lavede, ville du have fundet fejlen, der førte ham til at bruge segmentheapen, og det var en 100% overhead fra brugen af den lave fragmenteringsbunke i browserprocesser.
https://bugs.chromium.org/p/chromium/issues/detail?id=1014701#c9
Når det er sagt, er der nogle forbedringer, der kan gøres for at reducere påvirkningen. De falder i to områder, men ingen af dem er nemme.
1) Reducer mængden af forbigående heap-allokeringer, som browseren foretager. Dette vil kræve betydelige ændringer på tværs af hele browserens kodebase.
2) Forbedre ydeevnen af selve segmentbunken. Dette kan kun løses af Windows-teamet, og vi er ved at undersøge vores muligheder.På kort sigt er dette en god afvejning af en ressource for en anden, da brug af hukommelse/commit er et væsentligt smertepunkt for browserbrugere.
Desværre Google i aftes besluttede for at gå videre og deaktivere SegmentHeap. Det er blevet flyttet bag et GN-flag, så holdet kan fortsætte med at eksperimentere med funktionen, så det ikke er vejens ende.
Deaktiver segmentheapen som standard, og tilføj et GN-flag for at kontrollere det.
Der er en vis bekymring for, at prisen på segmentbunken ikke retfærdiggør omkostningerne (se crbug.com/1102281). Denne CL deaktiverer den som standard og sætter denne funktion bag et GN-flag for at lade os fortsætte med at eksperimentere med den.
via: Techdows
