Google disables SegmentHeap on Chrome due to performance regression

Reading time icon 3 min. read


Readers help support MSPoweruser. When you make a purchase using links on our site, we may earn an affiliate commission. Tooltip Icon

Read the affiliate disclosure page to find out how can you help MSPoweruser effortlessly and without spending any money. Read more

Google Chrome

In May, Microsoft released Windows 10 May 2020 Update for Windows 10 users. The new update came with SegmentHeap that allowed Win32 apps to improve the RAM usage. Soon after the release, Microsoft announced that it had managed to reduce the RAM usage on Edge using the new feature.

In June, Google also jumped on the bandwagon and announced it will be using SegmentHeap in Chrome’s manifest which will fix Chrome’s memory hogging behaviour. The feature was later enabled in Chrome v85 but after further testing, Google has gone ahead and disabled the feature on Chrome. Google noted that the feature was causing performance issues and hence it has been disabled.

With commit https://chromium-review.googlesource.com/c/chromium/src/+/2163163 landed, Windows >= 10.0.19041.0 (Windows 10 version 2004 and later) will opt chrome.exe into using the segment heap instead of the legacy heap. But which led to performance regression for WebXPRT3, Speedometer2, and JetStream2.

Microsoft, on the other hand, noted that it’s common for an app to trade one resource for another so the reduced memory usage meant an increase in the CPU usage. Microsoft further said that some improvements could be done to reduce the impact.

It is common practice to trade one resource for another. More often it’s increased memory usage for reduced CPU usage. In this case it’s increased CPU usage for dramatically reduced memory usage, or more accurately commit. If you looked at the commit Bruce made you would have found the bug that lead him to use the segment heap, and that was a 100% overhead from the use of the low fragmentation heap in browser processes.

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

That said, there is some improvement that can be done to reduce the impact. They fall into two areas, but neither is easy.

1) Reduce the amount of transient heap allocations the browser makes. This will require significant changes across the entire browser codebase.
2) Improve the performance of the Segment heap itself. This can only be addressed by the Windows team and we are investigating our options.

In the short term this is a good tradeoff of one resource for another as memory/commit usage is a significant pain point for browser users.

Unfortunately, last night Google decided to go ahead and disable SegmentHeap. It has been moved behind a GN flag so the team can continue experimenting with the feature so it’s not the end of the road.

Disable the segment heap by default and add a GN flag to control it.

There’s some concern that the cost of the Segment heap doesn’t justify its cost (see crbug.com/1102281). This CL disable it by default and put this feature behind a GN flag to let us keep experimenting with it.

Via: Techdows

More about the topics: google, google chrome, Google Chrome Canary, segment heap

Leave a Reply

Your email address will not be published. Required fields are marked *