Issue metadata
Sign in to add a comment
|
OOP-D M70 memory regression on stable channel compared to beta channel |
||||||||||||||||||||||
Issue descriptionThere is an increase in renderer and total memory usage with OOP-D enabled with Window M70 stable compared to beta. The thing I'm comparing between stable and beta is the change (percentage) in memory used for experiment group compared to the control group. Stable: https://uma.googleplex.com/p/chrome/variations/?sid=d2a5f7259d2fc192c1e9b5a5f4f6fb8e Beta: https://uma.googleplex.com/p/chrome/variations/?sid=890edde1e4a48215e8a5f31c6b43956c Memory.Total.PrivateMemoryFootprint on beta channel has a small regression at lower percentiles. This is expected (we're going to use a bit more command buffer memory) and matches perf bot results. The regression is probably still there at higher percentiles but it's smaller than variations due to noise. Beta channel matches what we've seen on canary and dev channels as well. Memory.Total.PrivateMemoryFootprint on stable channel has a consistent ~1.5% regression across all percentiles. Memory.Renderer.PrivateMemoryFootprint on beta channel isn't changed. This is what we expect as OOP-D is essentially a no-op for the renderer. Beta channel again matches canary and dev channels. Memory.Renderer.PrivateMemoryFootprint on stable however shows a consistent regression which isn't expected at all. Nothing really changes as far as the renderer is concerned. Memory.Total.RendererPrivateMemoryFootprint confirms what we saw in Memory.Renderer.PrivateMemoryFootprint. Beta channel shows no change and stable channel shows a consistent 1% regression. Memory.Browser.PrivateMemoryFootprint improves (which is again expected) on both stable (-0.7%) and beta (-1.5%) channels. However, the improvement is more larger on beta channel, so stable channel is again using more memory. Memory.Gpu.PrivateMemoryFootprint plus all the shared memory metrics look pretty similar between beta and stable. So for some reason the renderer process and maybe browser process is using more memory with OOP-D enabled for Windows M70 stable channel compared to M70 beta channel. Ideas for what could be causing this: 1. Differences in the population on each channel. Maybe there is something about beta/dev/canary users, eg. better average system specs, different usage patterns, different common extensions, etc. 2. Uptime difference between channels. If there was a slow memory leak and stable channel users had longer uptime they would have higher memory usage on average. 3. Intersection with another finch experiment. Maybe there is some finch experiment that decreases OOP-D group memory usage but not control group memory usage and that experiment isn't enabled on stable channel. Adding a few GPU and memory people for ideas on how to better understand this.
,
Nov 5
> The number of hits on Browser.PrivateMemoryFootprint is lower than the number on Gpu.PrivateMemoryFootprint. What filters/date/aggregation period were you looking at where you saw Memory.Gpu.PrivateMemoryFootprint counts being higher than Memory.Browser.PrivateMemoryFootprint counts? I see the opposite for the stable and beta links above, which is expected as sometimes the GPU process won't be running. > The increase in Total.RendererPrivateMemoryFootprint might also be related to the number of renderers. There seems to be increase in number of renderers consistently across all dates. If this experiment makes the user experience faster, then there is a chance that the users use more tabs. So, total renderer footprint might increase. The changes in individual renderer footprint is not significant. Interesting! I see that Memory.Total.RendererPrivateMemoryFootprint counts are higher for experiment vs control on stable but not on beta. Similarly Tabs.TabCount is higher for experiment vs control on stable but not on beta. That would explain a chunk of the extra memory usage at least. Were you looking at any other metrics for this?
,
Dec 17
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ssid@chromium.org
, Nov 2