On Mon, Jul 13, 2009 at 8:19 AM, Joel Stanley<[email protected]> wrote: > 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.
Wow, impressive. How much do you think multi-process hurts us? > 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. One piece to look at is the code that calls SetProcessBackgrounded(), which on Windows marks the process as one that can be paged out but on Linux is not implemented. I don't know how it decides it's ok to do that, but it'd be good logic to examine. I think it'd be pretty interesting to fully suspend background tabs, but doing it safely is likely tricky. For example, imagine a page that has Javascript that is driving a Flash plugin playing background music. > Other things to look at would be timers that fire 'too often', and > pausing animated content such as gifs and flash. Even for stuff like gifs that don't have audio, you could imagine a page with a very long animated gif, where I might switch away from the tab and expect it to be farther along when I come back. Here's an idea: when a page is in the background don't let it repaint. That means when you switch to it you'll have to wait for it to repaint, but maybe that's an ok tradeoff. (Maybe we do this already.) > 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. A final idea is simply looking at performance overall. We haven't yet looked at even a profile and we very well could be doing a lot of unnecessary work. For example, I believe the renderer spams the browser repeatedly with "set tooltip" messages as you move the mouse around. I think I saw a bug filed suggesting we could have the renderer only send the message if the tooltip changed. Maybe that's not enough work to waste much battery, though. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
