On Tue, Jul 14, 2009 at 01:52, Evan Martin<[email protected]> wrote: >> 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?
The full story is 128MB of RAM + 128MB of swap on a slow (class 4) SD card. Multi-process changes the game, at least wrt memory. Normally once you hit the memory ceiling the system is unresponsive until the OOM killer takes out something (on the OLPC XO this would often be X, losing the entire session). With Chrome, opening a 3rd tab results in the new renderer instantly crashing (if it's even starting?), leaving you restricted to two tabs but free to continue browsing in those two. So IMO, multi-process makes us fail in much nicer ways :) But we will hit that memory ceiling sooner due to the overheads of being multi-process. The ~500Mhz CPU is pegged when rendering, but the system goes near-idle once drawing has finished. Scrolling takes it back up to 100%. I haven't used it much, but will do more often going forward now that I can build using the tree. On the topic of the ARM build, it would be great if we could have a buildbot doing cross compiles. I filed a bug at http://crbug.com/16321, is there anything else I can do to follow that up? > 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'll take a look. My email was kicked off after discovering the SystemMonitor class, which I understand is only used for switching on and off high-res timers on Windows. These both sound like good switches for enabling efficient behaviour. > 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. I wonder if it would be possible to detect that sound is coming from a tab. Perhaps it's not worth it, as the case of IM in the background tab will be really hard to detect in a generic fashion. The only reliable way the browser will discover that a tab is inactive is for the user to tell it. Right click -> "Pause this tab"? This would be a UI win over my current `pgrep firefox | xargs kill -STOP` :) >> 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.) So we do this for GIFs. Can anyone tell me if background tabs re-paint themselves? If not, I'll add it to the TODO. > 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. > This is more generic, but perhaps more realistic. This would be best discovered by looking at IPC traffic going past? Thanks for the reply, Joel --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
