Google Chrome is known for being one of the faster and more fluid browsers out there, regularly showing up the more established competition like Microsoft and Mozilla. However this speed comes at a price and it’s been known for a while that Chrome is a system resource hog – it regularly chews up gigabytes of RAM on my system and it uses the GPU as much as possible to accelerate the UI and certain content shown in the web page. But according to Forbes, Chrome has long been a hog for a different reason altogether – they pin is as the source of a lot of unnecessary battery drain. Hit the jump to find out more.
Forbes contributor Ian Morris broke a story on the site last week alleging that Chrome was behind the severe battery drain he was seeing on his system. According to Morris, a little applet he downloaded to monitor the system clock inside Windows was telling him that not only is Chrome affecting the internal clock to improve speed, fluidity and responsiveness, it’s also waking up the processor 1000 times a second, when the idle average for calls to the CPU should be around 15.625ms apart, or waking up the CPU just 64 times every second. Morris says that other browsers don’t exhibit the same behaviour and that this is the reason why Chrome falls behind the competition when comparing battery life under Windows and Mac OS X.
“Well, when you open the most recent version of Internet Explorer, the rate stays at 15.625ms until the browser needs to do something where the rate must increase,” writes Morris in his column. “If you go to YouTube, say, and play a video IE will increase the rate to 1.00ms. When you shut that tab, and carry on with normal browsing, it will return to 15.625ms.”
“In Chrome though, it is increasing the rate as soon as the browser is opened, and it keeps it high until you shut the browser completely.”
He later reveals that in casual tests with his desktop computer, running Chrome on its own with a single tab increases power consumption by at most 5 watts, which for desktop hardware is insignificant. However, compare that same 5W drain in a laptop and you’re suddenly seeing battery life drops anywhere in the region of 15-25%. The problem is also more severe if you scale it up, with a set of, say, 200 computers in a workplace all running Chrome consuming about 1000W more than they should be. This is why Intel’s SSD 730 drives aren’t recommended for laptop use, because they overdraw on power to improve performance and responsiveness for datacenter applications.
Morris searched around more for clues on why Chrome exhibits this behaviour and found a multi-year-old bug tracker report for the Chrome browser, first filed on 29 September 2012. The bug, once reported on Forbes, has since been assigned to the Chromium team for investigation and they are now actively looking into why this is happening.
Some of their more recent comments on the bug tracker have revealed interesting bits about the inner workings of Google’s browser.
- Chrome, when running, disables V-Sync on the Windows desktop and implements an internal framerate limiter to avoid tearing
- It currently relies on battery status reports to influence the timer and ignored limitations imposed system-wide by the Windows Power Plan settings
- The problem affects Chrome wholly and even with a new patch, fixes can be nullified just by visiting certain websites like Reddit
- Some of the battery drain issues are caused by Windows not resetting the internal timer when going to sleep because it doesn’t override changes to the internal clock that other apps make
- The issue is present even when Chrome is closed if you have the option to run background processes even when Chrome is closed ticked (Menu>Settings>Show Advanced Settings>Scroll down to “System”)
It’s also a little funny when you read through the exchanges between the Chromium developers and realise that they themselves don’t have access to how Microsoft set up the tick-less internal timer in Windows 8 because there’s no official documentation available for it.
Many people are reading into this a little oddly and some are claiming that this isn’t the actual problem and that Chrome is just a resource hog. Well, this isn’t a problem on Windows 7, or Vista or XP. Some Linux distributions and base OSes don’t suffer from it either – it’s only a bug present in operating systems that have moved away from using a hardware timer for processes.
This same software-based internal clock is the reason why a number of results on HWBot were banned from submission from systems running Windows 8, because the clock could be modified on the fly by changing the FSB speed, causing benchmarks to report inaccurate results with inflated scores and causing Windows report time inaccurately as well. It’s worth noting that Morris’ tests were run on a Intel system – AMD-based Windows 8/8.1 computers seem to be exempt from these strange anomalies.
More testing is needed but I’ll continue to explore switching out Chrome for something else on my netbook. I’ll do some testing on my own of Opera Next, as it’s based on the Chromium project and may be subject to the same issues as well.