Gear & Gadgets / Product News & Reviews

Why Google took years to address a battery-draining “bug” in Chrome

As with many browser problems, the answer boils down to "blame Flash."

Aurich Lawson

A recent Forbes report says that Chrome on Windows uses up more battery than competing browsers, thanks to a high system timer setting. Windows uses a timer to schedule tasks. At idle, the timer on Windows is set to about 15 ms, so if it has no work to do, it will go to sleep and only wake up every 15 ms to check if it needs to do something.

Applications can change this timer, and other browsers like Firefox and Internet Explorer don't mess with it until they need to do something processor intensive, like playing a video. After the video is done, the timer is set to return to 15 ms so that the computer can idle again. Chrome, though, boosts the timer to 1 ms and keeps it there forever. The difference means that on Firefox at idle, the CPU only wakes 64 times a second. On Chrome, it wakes up 1,000 times a second.

In its Windows documentation, Microsoft notes that setting the system timer to a high value can increase power consumption by “as much as 25 percent.” This means that on a laptop, you'll get a shorter runtime with Chrome than you will on a competing browser. And the issue has been around for a long time. Forbes links to a bug report documenting the problem that was first filed in 2010.

So why did it take so long for Google to address the issue? While many paint the 1 ms timer as a "bug," Google consciously made the decision to set the system-wide timer at such a high rate and keep it there. Mike Belshe, a Chrome engineer and the inventor of the SPDY protocol, wrote a lengthy blog post back in 2010 justifying the use of the faster timer. The post says that "the default timers really are too slow... While processor speeds have increased from 500Mhz to 3Ghz over the past 15 years, the default timer resolution has not changed. And at 3GHz, 15 ms is an eternity." Google boosted the system timer from 15 ms to 1 ms to make Chrome run faster.

Google was also well aware of the changes this move would cause, saying, "The first side effect is that it is system wide. When you change this value, you're impacting global thread scheduling among all processes, not just yours. Second, this API also affects the system's ability to get into its lowest-power sleep states."

Google knew about the battery draining effects in 2010 but made the change anyway, which seems like a big trade-off for such a small speed boost. Google was initially worried about the effect it would have on users' systems, but after some research, the company decided that the timer boost was worth it. Belshe notes that "we discovered that every major multi-media browser plugin was already using this API. And this included Flash, Windows Media Player, and even QuickTime. Once we discovered this, we stopped worrying about Chrome's use of the API. After all—what percentage of the time is Flash open when your browser is open?"

In 2010 logic, this makes sense. Chrome was free to abuse the system timer for a speed boost because everyone else already did. The setting is system-wide, so if it was going to be set that high anyway, Chrome might as well take advantage of it. Nearly every website back then had some kind of multimedia plugin, so the system never got to idle anyway.

Today, though, things are different. Mobile rules everything, and battery life is more valued than a minor speed increase. Plugins are pretty much dead thanks to their banishment from the mobile Web, and the 1 ms timer went with them. The "bug fix" took four years because for much of those four years, the change wouldn't have mattered. With Flash less prevalent, Chrome went from abusing something because everyone else did to being the last to break a bad habit.

Google was also well aware of the battery issues the timer could cause. Belshe said in 2010 that "engineers at Intel pointed out that Chrome was causing laptops to consume a lot more power. So before Chrome 1.0 shipped out of beta, we modified it to turn off fast timers if it detects that the system is running on batteries. Since we implemented this fix, we haven't heard many complaints." Today, Chrome runs the higher timer, but it does so even on a laptop. So somewhere along the line, something happened to break the battery detection.

With greater attention placed on the problem, it's been assigned as high priority, so it looks like Google will once again be addressing Chrome's timer issues.

Expand full story

You must to comment.