Compositing memory investigation
pdr@chromium.org, Feb 2020
See also: updated internal version given as blink brownbag talk March 2020
Compositing memory
<div style="width: 500px; height: 500px;� background: linear-gradient(red, blue);� will-change: transform;">
500 * 500 * 4 bytes = 1 MB
Compositing memory investigation
Compositing memory metrics
System memory
Renderer (50th: 41 MB, 99th: 180 MB)
GPU (50th: 37 MB, 99th: 60 MB)
Browser (50th: 71 MB, 99th: 166 MB)
Total (50th: 188 MB, 99th: 622 MB)
These numbers from Pixel 3 (4GB, 2018 device), UMA
Compositing memory metrics
System memory
Renderer (50th: 41 MB, 99th: 180 MB)
GPU (50th: 37 MB, 99th: 60 MB)
Browser (50th: 71 MB, 99th: 166 MB)
Total (50th: 188 MB, 99th: 622 MB)
GPU memory (50th: 12 MB, 99th: 204 MB) "compositing memory"
These numbers from Pixel 3 (4GB, 2018 device), UMA
Memory ablation studies
Renderer memory ablation study (August 2019)
Large memory increases on LowEnd and 2GB devices has a high risk of affecting user engagement, stability and performance.
Experiment reducing compositing memory
DoNotCompositeTrivial3D: do not allocate memory for transform: translateZ(0);
<div style="width: 500px; height: 500px;� background: linear-gradient(red, blue);� transform: translateZ(0);">�
Memory savings: 500 * 500 * 4 bytes = 1 MB
Experiment reducing compositing memory
DoNotCompositeTrivial3D (design doc):
Compositing memory: -2.4% @ 50th, -4.4% @ 99th
Visible foreground renderer OOM crashes: -8.25%
GPU tile memory progression @ 50th: -2.42% (-387KB) 95th CI: [-4.24, -0.59]%
GPU tile memory progression @ 99th: -4.43% (-3.55MB) 95th CI: [-7.45, -1.45]%
Visible foreground renderer OOM crash progression: -8.25% 95th CI: [-16.26, -0.39]%
Experiment reducing compositing memory
DoNotCompositeTrivial3D (design doc):
Compositing memory: -2.4% @ 50th, -4.4% @ 99th
Visible foreground renderer OOM crashes: -8.25%
Draw interval regression: +4.7% @ 99th
Draw interval regression: +4.66% (+11ms) 95th CI: [+1.17, +8.18]%
Experiment reducing compositing memory
DoNotCompositeTrivial3D (design doc):
Compositing memory: -2.4% @ 50th, -4.4% @ 99th
Visible foreground renderer OOM crashes: -8.25%
Draw interval regression: +4.7% @ 99th�
Chose not to launch due to cost/benefit:
OOM crash improvement in context: -6 crashes / million pageloads
Draw interval regression: +4.66% (+11ms) 95th CI: [+1.17, +8.18]%
Reduce compositing under memory pressure
Idea! Apply DoNotCompositeTrivial3D under memory pressure (design doc)
Stability benefit without affecting as much content
Reduce compositing under memory pressure
Idea! Apply DoNotCompositeTrivial3D under memory pressure (design doc)
Stability benefit without affecting as much content
Android "memory pressure" is when we see a critical OOM signal
Did not work: memory pressure is not a strong enough signal for OOM.
Reducing memory
Can reduce memory with compositing changes
Found it difficult to justify if there are costs
Reducing memory
Renderer memory ablation study (August 2019)
Large memory increases on LowEnd and 2GB devices has a high risk of affecting user engagement, stability and performance.
Reducing memory
Can reduce memory with compositing changes
Found it difficult to justify if there are costs
Should we just use more compositing memory then?
Reducing memory
Can reduce memory with compositing changes
Found it difficult to justify if there are costs
Should we just use more compositing memory then?
AssumeOverlapAfterFixedOrStickyPosition
PreferCompositingToLCDText
Compositing memory investigation
UMA filters for low-end
There was an UMA filter for "Low Memory Device". It returned false for the majority of <= 1GB devices!
UMA filters for low-end
PSA: "Low Memory Device" is a subset of low-memory devices
Recent changes:
UMA filter has been renamed "Low End Device"
Low End ≈ Android Go
SysInfo::IsLowEndDevice now has lots of documentation
UMA filters for device class
You can filter for specific RAM ranges: "System RAM, MB"
Can be used for "device class" queries: "1GB class", "2GB class", ...
UMA filters for device class
You can filter for specific RAM ranges: "System RAM, MB"
Can be used for "device class" queries: "1GB class", "2GB class", ...
Caution!
1. Android Go devices act like their own device class
2. Carveouts make queries difficult
UMA filters for device class
Carveouts are where hardware (e.g., radios, DRM video) takes away system RAM. Results in inexact RAM thresholds.
Example:� Nexus 5 has 2GB of RAM.� Available system memory is 1854MB� A "2GB class" device query (2048 <= mem < 3072) won't include Nexus 5.
�Specific phones may be better than memory range queries� Hardware Class == Pixel 3
Summary of compositing memory investigation
�Links�Chrome memory image credit: CinnamonToesCrunch.�DoNotCompositeTrivial3D�Reduce compositing under memory pressure�PSA: "Low Memory Device" is a subset of low-memory devices
Memory pressure
Critical OOM signals are common
1. Open 10 tabs on Android, tabs 1-5 are likely to have been killed
2. Foreground signals are expected on well-performing pages:
Before Chrome
Youtube
Free
After pageload
Chrome
Free
Start Chrome
Youtube
Free
Chrome
Signal
Update from Kentaro's comment: This slide may not be correct with user level critical memory signals.