Google disabilita SegmentHeap su Chrome a causa della regressione delle prestazioni

Icona del tempo di lettura 3 minuto. leggere


I lettori aiutano a supportare MSpoweruser. Potremmo ricevere una commissione se acquisti tramite i nostri link. Icona descrizione comando

Leggi la nostra pagina informativa per scoprire come puoi aiutare MSPoweruser a sostenere il team editoriale Per saperne di più

Google Chrome

A maggio, Microsoft ha rilasciato Windows 10 May 2020 Update per gli utenti di Windows 10. Il nuovo aggiornamento è arrivato con SegmentHeap che ha consentito alle app Win32 di migliorare l'utilizzo della RAM. Subito dopo il rilascio, Microsoft ha annunciato di essere riuscita a ridurre l'utilizzo della RAM su Edge utilizzando la nuova funzionalità.

A giugno, anche Google è saltato sul carrozzone e ha annunciato utilizzerà SegmentHeap nel manifest di Chrome che risolverà il comportamento di monopolizzazione della memoria di Chrome. La caratteristica è stata successiva abilitato in Chrome v85 ma dopo ulteriori test, Google è andato avanti e ha disabilitato la funzione su Chrome. Google noto che la funzione stava causando problemi di prestazioni e quindi è stata disabilitata.

Con il commit https://chromium-review.googlesource.com/c/chromium/src/+/2163163 atterrato, Windows >= 10.0.19041.0 (Windows 10 versione 2004 e successive) opterà invece per chrome.exe per utilizzare l'heap del segmento del mucchio di eredità. Ma ciò ha portato a una regressione delle prestazioni per WebXPRT3, Speedometer2 e JetStream2.

Microsoft, invece, noto che è comune per un'app scambiare una risorsa con un'altra, quindi l'utilizzo ridotto della memoria significava un aumento dell'utilizzo della CPU. Microsoft ha inoltre affermato che potrebbero essere apportati alcuni miglioramenti per ridurre l'impatto.

È pratica comune scambiare una risorsa con un'altra. Più spesso si tratta di un maggiore utilizzo della memoria per un utilizzo ridotto della CPU. In questo caso si tratta di un maggiore utilizzo della CPU per un utilizzo della memoria notevolmente ridotto o un commit più accurato. Se hai guardato il commit che Bruce ha fatto, avresti trovato il bug che lo ha portato a usare l'heap del segmento, e quello era un sovraccarico del 100% dall'uso dell'heap a bassa frammentazione nei processi del browser.

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

Detto questo, c'è qualche miglioramento che può essere fatto per ridurre l'impatto. Cadono in due aree, ma nessuna delle due è facile.

1) Ridurre la quantità di allocazioni di heap transitorie effettuate dal browser. Ciò richiederà modifiche significative nell'intera base di codice del browser.
2) Migliora le prestazioni dell'heap del segmento stesso. Questo può essere risolto solo dal team di Windows e stiamo esaminando le nostre opzioni.

A breve termine questo è un buon compromesso tra una risorsa e un'altra poiché l'utilizzo della memoria/commit è un punto dolente significativo per gli utenti del browser.

Purtroppo ieri sera Google deciso per andare avanti e disabilitare SegmentHeap. È stato spostato dietro una bandiera GN in modo che il team possa continuare a sperimentare la funzione, quindi non è la fine della strada.

Disabilita l'heap del segmento per impostazione predefinita e aggiungi un flag GN per controllarlo.

C'è qualche preoccupazione che il costo dell'heap del segmento non giustifichi il suo costo (vedi crbug.com/1102281). Questo CL lo disabilita per impostazione predefinita e mette questa funzione dietro un flag GN per permetterci di continuare a sperimentarlo.

Via: Techdows

Maggiori informazioni sugli argomenti: google, Google Chrome, Google Chrome Canary, mucchio di segmenti

Lascia un Commento

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati con *