Chromium is the free software build of the Google Chrome web browser. It’s essentially the same as the Google code but will often be an older version, particularly when you get Chromium from Debian/Stable (or any other Linux distribution that doesn’t track the latest versions all the time) and compare it to getting Chrome straight from Google.
My wife is using Chromium on an AMD Opteron 1212 for all the usual web browsing tasks. Recently I’ve noticed that it takes a lot of CPU time whenever she leaves a Google web site open, that can be Google+, Gmail, or Youtube.
Web standards are complex and it’s difficult to do everything the way that one might desire. Making a web browser that doesn’t take 100% CPU time when the user is away from their desk may be a difficult technical challenge. Designing a web site that doesn’t trigger such unwanted behavior in common web browsers might also be a challenge.
But when one company produces both a web browser and some web sites that get a lot of traffic it’s rather disappointing that they don’t get this right.
It could be that Google have fixed this in a more recent version of the Chrome source tree, and it could be that they fixed the browser code before rolling out a new version of Google+ etc which causes problems with the old version (which might explain why I’ve never seen this problem). But even if that is the case it’s still disappointing that they aren’t supporting older versions. There is a real need for computers that don’t need to be updated all the time, running a 3 month old Linux distribution such as Debian/Wheezy shouldn’t be a problem.
There’s also a possibility that part of the cause of the problem is that an Opteron 1212 is a relatively slow CPU by today’s standards and it’s the slowest system I’m currently supporting for serious desktop use. I don’t even think it was one of the fastest CPUs available when it was released 4 years ago. But I think we should be able to expect systems to remain usable for more than 4 years. The Opteron 1212 system is a Dell PowerEdge tower server that is used as a workstation and a file server, so while I get desktop systems with faster CPUs for free I want to keep using the old PowerEdge server to avoid data corruption. As an aside I’ve been storing important data on BTRFS for a year now and the only data loss I’ve suffered has been due to a faulty DIMM. The filesystem checksums built in to modern filesystems such as BTRFS and ZFS mean that RAM corruption covers a greater portion of the risk to data integrity and the greater complexity of the data structures in such filesystems gives the possibility of corruption that can’t be fixed without mkfs (as happened to me twice on the system with a bad DIMM).
The consequences of such wasted CPU use are reduced CPU time for other programs which might be doing something useful, extra electricity use, and more noise from CPU cooling fans (which is particularly annoying for me in this case).
Any suggesstions for reducing the CPU use of web browsers, particularly when idle?
> It could be that Google have fixed this in a more recent version
> of the Chrome source tree, and it could be that they fixed the
> browser code before rolling out a new version of Google+ etc
> which causes problems with the old version (which might explain
> why I’ve never seen this problem). But even if that is the case
> it’s still disappointing that they aren’t supporting older
> versions. There is a real need for computers that don’t need to
> be updated all the time, running a 3 month old Linux distribution
> such as Debian/Wheezy shouldn’t be a problem.
What do you mean? Chromium is actually being constantly updated in wheezy to its latest stable version, so you always (with a small delay) have the recent one.
It’s highly doubtful that chromium version is the issue here. I’d recommend doing a strace of the CPU consuming process with timestamps enabled to see what it is actually doing. Btrfs is in question too because it can be unacceptably slow in some conditions.
With Firefox/Iceweasel I use the NoScript plugin. It is rather drastic; you have a choice to enable some/all scripts on a page, for it to work as normal, or you can have a mostly JavaScript-free web experience which may be a little broken.
I usually go for the latter, and it’s great. Web browsing is fast and efficient again. My computer wasn’t getting slower over time; web developers were just getting lazier and throwing more code at me.
But I’ve had to change some habits; if I’m trying to quckly find information and a site doesn’t render properly at all without JS, I may just go elsewhere. I completely forego certain web applications but will probably have an alternative not needing JS.
In my experience, the primary ongoing use of CPU in a web browser (i.e. not triggered by page load) is Flash.
Chrome has a setting available to not load Flash objects unless you click on them specifically; I expect this is available in Chromium as well. http://osxdaily.com/2011/06/03/enable-click-to-play-plugins-flash-chrome/ is the first obviously relevant google result.
Actually Debian Stable (Wheezy) seems to track Chrome Stable (currently at 28.0.1500.95) very well. Note that Chrome Dev is at 30.0.1599.10 now and obviously Chromium Trunk has even greater version number.
You can track Chrome releases using https://omahaproxy.appspot.com/ and http://googlechromereleases.blogspot.com/ .
Please file a bug for the behavior you see.
Not an answer, but I swapped from Firefox to Chrome on my OS X and Linux desktops because Chrome uses less CPU than firefox when on Google’s pages (at least groups and gmail). On Windows I don’t notice any difference. So there are subtle differences in the way codebases interact with different sites, and Flash is not a factor in this case.
On my core i7 Macbook Pro, Firefox stabilises at about 12% of one core when idle in gmail, which is crazy. Chrome stabilises at <2%. Similar results on Linux both in a virtual machine on the Mac and two older notebooks running Linux (arch).
I noticed this recently after I decided to move entirely to webmail. I use Chrome beta channel. So my observation is based on a recent code base. Although discussion on the internet of this phenomenon is not new (in the context of high CPU being a Firefox bug).
It's weird that Chromium would be different, but I don't use Chromium.
Steven: I’ve been concerned about the privacy implications of Javascript and had idly considered NoScript. I guess I should investigate it further.
dsr: Thanks for the suggestion but I don’t think I need to do that. I have Squid set to block Flash by default and I only enable it for selected sites. I don’t think I’ve enabled anything that would be used by Google.
Pawel: Thanks for that information. You are correct that I should file bug reports whenever possible, but this is difficult to reproduce. Maybe the NoScript plugin will allow me to determine which script is at fault.
tim: At the time I switched to Chromium it was reported as having significantly faster JavaScript than most browsers due to pre-compiling. In regard to your 12% number, 12% of an i7 might be about equal to 100% of a core of an Opteron 1212.
Also I’m not certain that Chromium is different from Chrome in this regard. But I have to assume that Google wouldn’t have the latest Chrome performing so badly with their own web sites, what type of foolishness would that be?
ÐлекÑей: Your comment got caught by my anti-spam measures, maybe it regards non-ASCII names as spam, sorry about that.
I’ll do an strace next time, but such traces won’t directly show where the problem is, it will only indirectly show it as the code between two system calls. If the process is one of the sandboxed processes then it probably won’t show anything useful.
As for BTRFS, that’s not likely. It’s user-space CPU time that’s being used and I don’t think that BTRFS can affect that.