It has been five years since we did a benchmark of web browsers effect on battery life and a lot has changed. Back then, our testing included Opera 9 & 10, Chrome 2, Firefox 3.5.2, Safari 4, and IE8. Just looking at those version numbers is nostalgic. Not only have the browsers gone through many revisions since then, but computer hardware and the Windows operating system are very different as well.

Windows Timers: Computer Architecture & Google Chrome

Before we get to any testing of battery life, we need to provide some background information on some of the changes, which requires a deeper understanding of how operating systems and hardware interface with each other. If you've browsed tech news recently, there has been coverage of a Google Chrome design decision from 2010. To recap, Google Chrome on Windows requests the operating system use a 1ms timer in an effort to increase web page rendering speed. Faster is better, but there is a problem with this technique.

For those unfamiliar with OS timers, they form a core component of any operating system. There are two fundamentally different ways to handle timing in a computer system, polling and interrupt modes. A polling system consists of software and hardware that continuously checks to see if something of interest has happened. For example, if a driver sets up a hardware device (i.e. a sound card) to acquire input and then continuously reads memory to check for new values, this is a polling system. However, if the driver sets up the device to acquire and then waits for interrupts (hardware notifications) that new data is available in memory, this is an interrupt system.

In general, interrupt mode is preferred as it saves significant resources and allows other threads to work while the corresponding thread sleeps. The vast majority of API calls a software developer has available do not even provide timing mode selection and simply use interrupt mode. Otherwise, a single application using polling could easily eat up an entire CPU core. There are other factors as well, like preemption, but they are out of scope of this article.

There's a problem with interrupt mode, however: it is slower for a variety of reasons. First, there is interrupt latency. Compared to polling mode checking for something to happen over and over, interrupts are always going to lose.

As an example, if I watch someone building a piece of furniture the entire time, I know exactly when they finish and I can use the furniture. On the other hand, if I wait for the builder to tell me, I could do other things in the meantime (work, sleep, play games, etc.). Of course I wouldn't know exactly when the furniture is ready and there would be a delay between when the furniture is complete and when I first begin using it.

General purpose operating systems like Windows are not typically concerned with interrupt latency. This is more important in embedded mechanical controls like those in your car. But there's another reason interrupts are slower than polling: timer coalescing.

To save power, Microsoft uses timer coalescing in Windows. Applications and drivers waiting for an event can specify their timeout in milliseconds, but in most cases the request time will be rounded to a multiple of Window's 15.6ms default timebase (prior to Windows 8, more on that later). For example, if I wrote some code that waits for an event for 200 milliseconds, Windows might actually sleep my thread for 202.8ms. When two threads request timers, this technique helps Windows continue to wake up at roughly 64 times per second instead of twice as much, 128 times per second.

The results of timer coalescing is that a web browser or other application could theoretically wait up to 15.6ms even when it requests to be scheduled in 1ms interrupts. When push comes to shove, some applications bypass the regular timer mechanism and ask Windows to use a 1ms timer, circumventing these delays. This handicaps CPU and OS power saving features because the longest the hardware and operating system can ever sleep is 1ms. Factoring in thread work time and wake time, sleep duration is likely much less than 1ms.

The power penalty of applications requesting a 1ms timer is exacerbated in Windows 8. In Windows 8, Microsoft maintains the same timer coalescing and timer request API calls, but they have implemented a tick-less kernel under the hood. With a tick-less kernel, the operating system doesn’t just try to round sleep times to a 'default timer resolution' of 15.6ms like Windows 7 and prior did, but instead at every wake event, Windows 8 analyzes the upcoming timed events and intelligently schedules its next wake up time. Therefore, sleep times could be either shorter or much longer than the previous default of 15.6ms. Depending on the distribution of wake up times, this could save significant power. Microsoft provided a blog post with some detail and data regarding the move.

Microsoft did not provide detail on what applications were running when they performed this test. However, we can tell from the data that Chrome was not running, otherwise the only values in the distribution would be at 1ms and below. And that's the crux of the problem.

When Intel launched Haswell one of the focus points was idle power consumption. The theory is when you’re staring at a static screen reading an article or the device is ‘locked’, you can save significant battery life. Consider the following charts of power use for a desktop system:

Idle Power
The idle power of even a desktop Haswell is significantly better than Ivy Bridge

Load Power - x264 HD 5.0.1 Benchmark
But the load power is the same or worse

Intel spent many years designing Haswell as an improvement over Ivy Bridge for power consumption, but they are at the mercy of application developers. If an application wakes the device up for work every 1ms, the idle power benefits of Haswell don’t have nearly the impact they could.

The developers of Chrome are not ignorant to this and optimized Chrome to turn off its 1ms timer request if the system is running on battery power. However, this optimization is not functional and Chrome unfortunately always requests a 1ms timer. Other developers have criticized this timer technique in Chrome, pointing out that other browsers and high performance applications do not follow this same design pattern and that relying on precise interrupts from a general purpose OS is fundamentally a flawed design. They have likened it to old video games that changed speed with the MHz of the CPU.

By way of comparison, IE and Firefox use a frame rate limiting technique, where they use the default timer resolution of 15.6ms but if a website requests a 1ms refresh rate, they check the system clock after waking up and compute how many iterations to perform to achieve a virtual 1ms update rate. For example, if the browser wakes up after 13ms, then perform 13 iterations before sleeping again. The result is that they do more work less often.

The Test
POST A COMMENT

112 Comments

View All Comments

  • normadize - Wednesday, August 13, 2014 - link

    This had the opportunity to be a very valuable test but as it stands, it isn't.

    First, excluding Mac OS X (and Linux) is a big negative - at least it could have had a less misleading title, e.g. add "under Windows" to be fair.

    Secondly, and more importantly, the testing methodology is very vague and doesn't state how often the requests, scrolls etc are made. It also does not say how many tabs were open and what kind of content was browsed (static vs dynamic/animated ratio at least?), which websites?

    The most important aspect is that it seems it does not replay an actual user session of 10+ hours exactly as it happened, with large pauses between clicks and scrolls.

    There is a huge difference between actual idle/low usage and this article's seemingly rushed simulated idle/low usage. An actual idle/low usage spans a lot longer time scale, during which the user is reading (or away) and the browser is taxing the battery due to timers/IRQs of animated GIFs / Javascript / Flash / etc that keeps running in the background and in other tabs. Different browsers behave VERY differently in this scenario. The critical aspect is that this is the state the browser spends most time in.

    As it stands, although I commend the effort, this test is of little use to me, and in my opinion it should not be taken seriously due to the poor methodology and its reporting.

    A true test that lives up to the current (misleading) title would be a replay of an actual real-world browsing session, exactly as the user "played" it.
    Reply
  • dstarr3 - Wednesday, August 13, 2014 - link

    Surely IE would give you the best battery life, as it would rid you of any desire to use the internet and make you pocket your phone. Reply
  • wantthefun - Thursday, August 14, 2014 - link

    I am on Surface Pro 2 and I find Chrome reduces my battery life more than IE. I have almost quit using Chrome, because of this reason (switched to IE metro). I wonder if the extensions, or running it in a non-simulated environment with all the sync and programs installed makes a difference, else it could be the use of flash... Not sure, but does not agree with my 8 months of experience with this computer, had to make an account to chime in. Thanks for publishing this! Reply
  • hallstein - Thursday, August 14, 2014 - link

    Safari for Windows was discontinued several years ago and should definitely not be included in this article.

    I thought this would be super interesting, especially as Apple have made a big fuss about Safari’s energy efficiency, alas it was windows-only. For mac, this could have been a really interesting contribution to the safari-chrome-firefox debate.
    Reply
  • janawatson - Monday, August 18, 2014 - link

    I keep seeking for new fighting games. Can anyone provide me some new links? Thank you Reply
  • Heavensrevenge - Tuesday, August 19, 2014 - link

    Then explain this: I set my power plan to "Power Savings and start Chrome AFTER setting to the power savings power plan and here:
    http://i.imgur.com/HlMxr3L.png to see chrome NOT requesting the higher timer WHILE running sunspider twice during the recording period
    AND
    https://mega.co.nz/#!thBUCKCT!RxVWNSEbw0b_-tCJCdrc... is the entire energy report that shows all the details of more chrome.exe processes vs just that single screen shot with 1 entry + the timer resolution to show u chrome doesn't ONLY request the high resolution timer no-matter what.
    Reply
  • djsvetljo - Tuesday, August 19, 2014 - link

    Chrome has huge issues with utilizing graphic card acceleration for videos. It does NOT work on certain pro cards, such as NVIDIA NVS series, as well as certain Intel GPUs. As a result, a video that is a piece of cake for a GPU struggles to play with CPU only resulting in super high CPU usage, which results in high power consumption. I have 3 machines that suffer from the same issue, some don't - it depends on the GPU model. Same machines tetsed with FF or IE and CPU load is times less. Reply
  • darwiniandude - Sunday, August 24, 2014 - link

    Can you test Safari Firefox and Chrome under OS X? And the others under Windows / Bootcamp on the same hardware? Would be good to test and challenge the 'OS X gets better battery life' rumor/myth Reply
  • mtcn77 - Wednesday, August 27, 2014 - link

    Could this Micro-trololo article EVER be biased by any outside variable unbeknownst to the almighty editor? Something other than the new kid in town, the Google? No! ABSOLUTELY NOT! Microsoft Windows is the best engineered piece of hardware and this is an issue for Google to fix (only for Windows). Reply
  • John.S - Sunday, August 31, 2014 - link

    This article is a bit miss leading, in future you may want to consider that these browsers all run differently on different OS. Run these tests again on OSX or Linux and you will find different results. I point this out because you put in Safari due to the "OSX / iOS crowd". This is a "MS Windows" , "browser face-off", not an overall "best browser face-off" Reply

Log in

Don't have an account? Sign up now