Improvements to low-end logic triggering |
|||||
Issue descriptionThere are several improvements that have been discussed: 1) There are two types of triggering in the code today, some places trigger off of SysUtils.isLowEndDevice() and others examine RAM size for 512MB only optimizations (e.g. 16-bit textures). We should fix the RAM size checks to use some common function indicating this is "extreme" intervention vs "regular" low-end intervention. 2) There has been a discussion over using Android's IsLowRam ActivityManager check vs the RAM check that we use today. In the past we've had a problem where devices with large screens and 2GB of memory would set Android's flag. I've recorded a UMA metric (https://uma.googleplex.com/p/chrome/timeline_v2/?sid=471cdddc4e042854eba8634f760be57e) to see how often Android's check and Chrome's check match and the parity is pretty close on Android N & O, but quite a bit mismatched on Android K&L. The reason to update is that there are expected to be more restrictions in P on /proc/meminfo API that we're reading to determine our RAM, so we may need to do so at least on some newer versions. 3) We may want to consider extending IsLowRamDevice() check to 1GB devices even on older OSes. What memory ablation results have shown is that devices in 512MB - 1GB range behave a lot like the devices in <512MB range when it comes to memory performance, so it may be worth trying an experiment to do that. The sensitive part of the task is that today IsLowRamDevice() flag changes Chrome UI for tabswitcher, so the options are to separate user-visible from user-invisible and only do the latter retroactively or to bite the bullet an make the change and hope that it performs sufficiently better that the users will forgive the clunkier UI :)
,
Jun 14 2018
I think it'd be reasonable to at least pursue 3) where we'd not update the UI-treatment, but in general treat <=1GB as low end devices across all operating systems.
,
Jun 18 2018
Sure, we could try and split the two but I thought a lot of memory savings come from reduced graphics quality (16-bit). Some might see that as a bigger change than tabswitcher so I think we need to verify whether that's where memory savings are coming from and if-so run an experiment or launch+holdback to evaluate the change
,
Jun 18 2018
16-bit is a fair bit of savings, but we didn't even launch that for 1GB Android Go devices. The primary reason is that 1GB devices typically come with better screens and 16-bit in addition to just the loss of quality has a number of other really weird rendering artifacts. IMO, moving all 512-1GB devices to 16-bit is too aggressive a move. I don't remember what the savings exactly for each feature are, but I think we'd see some pretty reasonable reductions even if we launched without 16-bit. The other thing we cap at 512MB is removing hardware acceleration on Android UI in favor of software path. It saves us as much as 10MB on some chipsets, but causes a lot of ugliness in the UI. I would also be hesitant to have more phones experiencing that. I do think non-user visible optimizations should definitely be applied. + Eric who might have an opinion on this
,
Nov 21
,
Nov 21
Egor: is this something Paris folks might want to pick up?
,
Nov 22
I like the potential impact of this. With new team members joining we may have some room for this, though we are not done prioritizing intro projects yet. In any case, we've been doing some memory stuff recently, so I guess it is fair to speculatively grab it for now :)
,
Dec 14
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by yfried...@chromium.org
, Jun 14 2018Labels: -Pri-3 Pri-2