[chromium-dev] Chrome low-power mode

[Aurimas Liutikas]

I was curious if anyone ever toyed around with an idea of "low-power mode" in Chrome?

The problem that I am thinking about is when your phone or laptop is down to 10% battery and we have Chrome going full speed, thus draining the precious battery. I think it would be interesting to see if Chrome could switch to a low power mode where we sacrifice some of the performance/quality to extends user's battery life in low battery situations.

Thoughts?

Aurimas

[Dongseong Hwang]

That's good idea. I also think we need "low-power mode" for mobile.

From graphics perspective, In "low-power mode", we can decrease refresh rate of the compositor. i.e. less than 30 FPS.

[Scott Hess]

Insofar as there are reasonable approaches to this, why should they only apply when you're low on power?

As an example, if the user is low on power and wants to keep playing Angry Flapper for the remaining five minutes, that's really their call.  Contrawise, if we have a background tab which we could spin down when we're in a low-power state, why not just spin it down all the time and not waste power in the first place?

IOW, the key problem here is intuiting where the user's desires diverge from the website's desires, and that doesn't get easier just because you're low on power.

-scott

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Alexandre Elias]

I think the code/testing complexity of a "low power mode" would only be worth it if we can achieve an order of magnitude improvement in power usage, whereas in reality we're unlikely to discover more than marginal gains (we still need to use the network, layout the page, run javascript, send frames to the screen, etc -- and it's unclear making that stuff run slower would actually decrease power usage, it might even increase it).  So I think our power efforts would be better spent on general-purpose improvements.

--
Alex

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Antoine Labour]

On Tue, Apr 22, 2014 at 2:08 PM, 'Alexandre Elias <ael...@google.com>' via Chromium-dev <chromi...@chromium.org> wrote:

I think the code/testing complexity of a "low power mode" would only be worth it if we can achieve an order of magnitude improvement in power usage, whereas in reality we're unlikely to discover more than marginal gains (we still need to use the network, layout the page, run javascript, send frames to the screen, etc -- and it's unclear making that stuff run slower would actually decrease power usage, it might even increase it).  So I think our power efforts would be better spent on general-purpose improvements.

--
Alex

The places where it could have an impact is for everything "speculative" we do, e.g. prefetching/prerendering.

Antoine

[Robert Flack]

I agree with Scott here, if there are tradeoffs we would make to save power over improved performance and/or low latency UI etc we should do them all the time to extend total battery life as much as possible rather than just when the battery's almost dead to extend the last X% of battery life.

That being said, when a device is plugged in we could do battery draining things we wouldn't normally do.

[Antoine Labour]

On Tue, Apr 22, 2014 at 2:23 PM, Robert Flack <fla...@chromium.org> wrote:

I agree with Scott here, if there are tradeoffs we would make to save power over improved performance and/or low latency UI etc we should do them all the time to extend total battery life as much as possible rather than just when the battery's almost dead to extend the last X% of battery life.

Why should power always trump performance?

Antoine

[Aurimas Liutikas]

While generic power saving changes/refactorings are great, they do not happen very often because we never want to regress on performance.

Personally, I think we can be much more aggressive in sacrificing the performance on low battery situations because users already have decreased expectations for performance when device is low on battery. A lot of phones come with "power saving" modes that throttle CPU and dim the display.

I understand that added complexity might make it a showstopper for ever shipping this. I just wanted people brainstorm some possible ideas.

Aurimas

[Alexandre Elias]

I agree with Antoine it's reasonable to disable prerendering on low power, as that's already an optional, heuristically triggered thing, so it wouldn't add much complexity.

I think the system is in the best position to make changes like throttle the CPU clock rate or dim the display.  As an app we don't have a lot of hooks to do things with a similar impact.

I think our lack of focus on general power improvements so far has been mostly due to lack of ability to measure it.  I'm hopeful that once we get good bots, we can start to identify problem areas and attack them, and make informed tradeoffs if any of them do risk a performance regression.  And we will probably identify various problems that don't call for a power/performance tradeoff at all, but is just pure bad behavior we can fix.

--
Alex

[Robert Flack]

TLDR; I agree that power doesn't always trump performance, what I'm saying is that an arbitrary battery level at which to start saving more power with a degraded experience doesn't make sense to me. I'd rather give the dial to the user if we think that we're regressing performance so that they can decide when it's worth it to them to save battery life.

As an example, let's say we can cut power usage in half by sacrificing performance, and that the battery lasts 5 hours and the proposal is to enable power saving at 20% battery left. If we think that the performance tradeoffs make for a bad user experience then I may want to only have 5 hours of battery life but a great experience until the device dies. On the other hand, if extra battery life is worth the performance tradeoffs, I would much rather my device last 10 hours than to only turn these power saving features on at the last hour to get a total of 6 hours of battery life.

[Antoine Labour]

On Tue, Apr 22, 2014 at 9:06 PM, Robert Flack <fla...@chromium.org> wrote:

TLDR; I agree that power doesn't always trump performance, what I'm saying is that an arbitrary battery level at which to start saving more power with a degraded experience doesn't make sense to me. I'd rather give the dial to the user if we think that we're regressing performance so that they can decide when it's worth it to them to save battery life.

As an example, let's say we can cut power usage in half by sacrificing performance, and that the battery lasts 5 hours and the proposal is to enable power saving at 20% battery left. If we think that the performance tradeoffs make for a bad user experience then I may want to only have 5 hours of battery life but a great experience until the device dies. On the other hand, if extra battery life is worth the performance tradeoffs, I would much rather my device last 10 hours than to only turn these power saving features on at the last hour to get a total of 6 hours of battery life.

A slow machine beats a dead machine - even with a pretty agressive perf tradeoff.

However, if your battery life is 5h at full perf and 10h in degraded experience, but you plug in the machine after 4h, then it would have been a bad choice to go into degraded experience at any point.

So I don't think it's true that the best choice is constant over the full range of battery level. It's not a black-and-white "good UX" vs "bad UX".

That said, I don't think this is the kind of things the user should have to deal with / micromanage.

Anyway, data first.

[Scott Hess]

On Tue, Apr 22, 2014 at 9:56 PM, Antoine Labour <pi...@google.com> wrote:

On Tue, Apr 22, 2014 at 9:06 PM, Robert Flack <fla...@chromium.org> wrote:

TLDR; I agree that power doesn't always trump performance, what I'm saying is that an arbitrary battery level at which to start saving more power with a degraded experience doesn't make sense to me. I'd rather give the dial to the user if we think that we're regressing performance so that they can decide when it's worth it to them to save battery life.

As an example, let's say we can cut power usage in half by sacrificing performance, and that the battery lasts 5 hours and the proposal is to enable power saving at 20% battery left. If we think that the performance tradeoffs make for a bad user experience then I may want to only have 5 hours of battery life but a great experience until the device dies. On the other hand, if extra battery life is worth the performance tradeoffs, I would much rather my device last 10 hours than to only turn these power saving features on at the last hour to get a total of 6 hours of battery life.

A slow machine beats a dead machine - even with a pretty agressive perf tradeoff.

However, if your battery life is 5h at full perf and 10h in degraded experience, but you plug in the machine after 4h, then it would have been a bad choice to go into degraded experience at any point.

So I don't think it's true that the best choice is constant over the full range of battery level. It's not a black-and-white "good UX" vs "bad UX".

That said, I don't think this is the kind of things the user should have to deal with / micromanage.

Anyway, data first.

As I said earlier, if the user wants to play Angry Flappers in spite of being low on power, we should let them do so in as power-efficient a way as we can, 100% of the time.  If things the user is not using are soaking up power, we should not do those things.  Users don't need coddled, regular mobile apps don't generally go into weird end-game mode when the power gets low, they generally run normally right up until the system pulls the plug.

For optional performance optimizations we do like pre-fetching and pre-rendering, IMHO we should be really certain that we're making a strong power/performance tradeoff for the user AT ALL TIMES.  We shouldn't prerender something we aren't certain of simply because we have enough power to do it.  We shouldn't spend the user's potentially-metered bandwidth pre-fecthing things just because we have power to spare.

This isn't really any different than using the user's other resources like memory and disk space and CPU.  We don't go into some odd mode when the user runs low on disk, and almost all of our attempts to do so when they run low on memory haven't worked well enough to maintain.  [Which is not to say that I think we're always good custodians of user's memory and disk space and CPU.  I'm just saying if we know how to be materially better, we should just do that.]

-scott

[Scott Hess]

Hmm, and to be clear - really the underlying thing I worry about with dynamically-changing operational modes like this is that nobody doing development is going to test those cases.  So Chromium developers might degrade/break that case because they never test it.  Web developers certainly aren't likely to test it.  So instead of some beautiful battery-extending slide at the end, maybe we have a bunch of janky/glitchy web pages which potentially don't even use less battery as all of the ad-hoc stuff kicks in.

Whereas things which aim to use less of a resource 100% of the time are more likely to keep making progress in the right direction.

-scott

[Marcus Bulach]

The chrome perf team is leading an effort to optimize for battery (on top of optimize for speed, optimize for memory and optimize for size). 

Out of all these dimensions, "battery" is certainly the trickier and harder to measure, and the trade-offs are not fully deterministic.

We're in early stages, but in telemetry there's already a few metrics for power (where HW/SW exposes it), and we're also adding 'derived' metrics.

This thread hit the nail in the head ;) but just to make it explicit. There are two sides of it:

1) reducing overall power consumption: that's a no brainer, we must do it, period. :) Remove All The Busy Loops!! of course, there are no low hanging fruits here... but in general, making chrome more efficient, say, faster rasterization, more efficient parsing, etc.., will help..

2) "speculative optimizations" / "elastic adaptation": last year, we've introduced "memory size" in a few places, like cache sizes... we used to have buffers with "one size fits all", which were not a good fit when we had to scale from 512MB small android devices all the way to huge desktops with multiple GB available. Chrome's usage is also fairly different in such environments, and so should be the optimizations we have in place... We also hooked up "memory pressure signals", so some of these speculative buffers can be flushed when needed.

We haven't done anything about "battery" yet, but there seems to be a good opportunity here (separate discussion on-going with the network team).

Whilst I fully agree with Scott, we should never waste anything and should aim for a 100% hit-ratio on all caches / speculative fetches / etc..., the reality is that the boolean decision to pre-fetch is based on a series of heuristics, like Antoine said.

One of the signals to take into account when deciding such speculative tasks is, potentially, battery level: the less battery we have available, the higher these thresholds should be to kick in the speculative task...

These efforts aren't mutually exclusive: we can keep improving our "hit ratio" whilst tweaking the battery level curve.

Thanks,

Marcus