---------- Forwarded message ----------
From: Ryosuke Niwa <rn...@google.com>
Date: Mon, Jul 13, 2009 at 8:34 AM
Subject: Re: [chromium-dev] Improving power usage
To: j...@jms.id.au
Hi, I think there was a recent discussion regarding performance, in which
someone suggested to suspend inactive renderer processes. I think the
problems pointed by others were that we need to have some threshold for
suspending a process because users may switch between tabs frequently (e.g.
comparing websites), and we also need to consider users who want to keep
websites alive background (e.g. AJAX chat service).
Ryosuke Niwa
On Mon, Jul 13, 2009 at 8:19 AM, Joel Stanley <j...@jms.id.au> wrote:
>
> Hello,
>
> I'm a Summer of Code student working with Dean. My interests are the
> Linux port, specifically ensuring Chromium behaves well on low spec
> machines.
>
> So far I've spent my 'summer' (it's winter here in Australia) on the
> ARM port of Chromium. As of the recent v8 gyp changes, the tree can
> build for ARM (and thumb, for a binary that's around ~25% smaller) and
> I've used it to browse on real hardware; the Beagleboard, an OMAP3
> based ARM board with 128MB of RAM.
>
> I've been looking into what to work on next. I'd like to investigate
> the possibility of reducing the amount of work being done when running
> on battery.
>
> On my laptop I send SIGSTOP to Firefox when I'm not using it, to save
> battery without losing state. This saves me 1 Watt when running Gmail
> in Firefox 3, or around 8% of the system power draw on my Thinkpad
> X300.
>
> As we're multi process with Chrome we could instead suspend any
> background renderers, plugin and extension processes without affecting
> the foreground tabs.
>
> Some obvious gotchas
>
> - when tabs share renderers, we can't indiscriminately stop background
> tabs
> - we can't just sigstop the renderer process, as the browser will
> think it has crashed
>
> Other things to look at would be timers that fire 'too often', and
> pausing animated content such as gifs and flash.
>
> Wakeups are not too bad, but any savings will mean longer lasting
> batteries:
>
> 28.4% (187.4) firefox-3.5 : hrtimer_start_range_ns (hrtimer_wakeup)
> 4.1% ( 26.9) chrome : hrtimer_start_range_ns (hrtimer_wakeup)
> 2.3% ( 15.0) chrome : ep_poll (process_timeout)
>
> (Powertop output of Firefox 3 vs Chromium trunk, one tab running Gmail, on
> Ubuntu Karmic)
>
> Perhaps we could run a powertop bot, that monitors an idle session
> with a few tabs opened to catch any regressions with timers.
>
> I plan to spend some time looking into this. Feedback and suggestions
> would be appreciated.
>
> Cheers,
>
> Joel
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
