Wednesday, September 3, 2008

Google Chrome the “Fattest” of them All

Earlier this week, we posted our findings from a 3-way browser comparison we had conducted featuring Internet Explorer 7, Internet Explorer 8 (Beta 2) and Firefox 3.01. As we were going to “print,” we learned that Google was readying its own foray into the browser market – Google Chrome – prompting us to quickly revisit our test scenario to add this high-profile newcomer to the mix.

Note: For more information on the, or to register for your free Analysis Portal account, visit

What we found was truly shocking: After re-executing our 10-site, multi-tab scenario across all 4 browsers, we discovered that it is Google Chrome, not Internet Explorer 8, that is the true memory consumption leader.

With a peak working set (324MB) just shy of IE 8’s updated 332MB mark, Chrome put a massive hit on available memory for our 2GB Windows XP (SP3) test system. And when we switched our focus to the average working set, Chrome actually topped IE 8 with an impressive 267MB footprint (compared to 211MB for IE 8).

Figure 1 – Average and Peak Working Sets

Of course, both browser look absolutely porcine when compared to the lean, mean Firefox 3.01 (151MB peak, 104MB average working set size). And lest we forget, IE 7 continues to hover somewhere between the fit & trim Firefox and the obesity that defines Chrome/IE 8 (209MB peak, 142MB average).

One area where the byproduct shares common ground with Chrome is average CPU utilization. Both products chew-up CPU bandwidth much more aggressively than either of the IE variants, with Chrome actually outpacing Firefox by 2 percentage points (45% to 42% for FF). Contrast these numbers with IE 8 (24%) and IE 7 (13%) and you begin to see that, when it comes to gobbling up CPU cycles, Chrome and Firefox are in fact birds of a feather.

Interestingly, the one place where Chrome completely befuddled us was in its use of threading. Both Firefox and IE 7 spawn a relatively modest number of threads (25 and 43, respectively), a fact related to their reliance on a single process instance to handle all tabbed sessions. By contrast, IE 8 spawns potentially hundreds of threads (153 in our latest test round), and spreads them out across its various instances (in our case, 6 discrete copies of iexplore.exe).

Figure 2 – Average and Peak Thread Count 

Given its use of a similar, multi-process model, we would have expected Google Chrome to introduce a comparable thread workload. So we were understandably surprised to discover that Chrome had spun a much more manageable 48 execution threads at the peak of the test scenario (10 sites loaded into 10 separate tabs). Even more surprising was how these threads were distributed: 25 of them belonged to the initial Chrome process instance (i.e. the one that’s created when you first start Chrome); the rest were distributed almost evenly across the other process instances – in our case, 2 threads per instance over 12 discrete instances (with one instance grabbing an extra 3 threads for unknown reasons).

Our guess – and it really is just that until we get confirmation – is that those initial 25 threads are there primarily to handle the base UI functions (client window, address bar, menus), and that all subsequent tabs/processes are created with just two execution threads to handle all of the the core rendering functions for that instance. It’s an interesting design, one likely made possible by Chrome’s modular architecture. And while it may not deliver the kind of massive parallelism that Microsoft seems to be shooting for with IE 8, it should serve to offset Chrome’s voracious appetite for memory. We shudder to think what Google’s browser would look like if it incorporated Microsoft’s overwhelming threading model.

Bottom Line: Chrome, like IE 8, is a browser designed with tomorrow’s hardware in mind. It’s use of a multi-process tabbing model – which, according to Google, helps isolate failures and protect complex web applications (like GMail or Google Docs) – means that it will always use more memory than Firefox, IE 7 and similar, single-process browsers. How such model will hold up under heavy use, especially on today’s hardware, remains to be seen.

Users may decide that the added protection of isolated tab processes is worth the cost in terms of browser “memory bloat.” However, Microsoft is also incorporating isolated tabs in IE 8, albeit on a smaller scale (just 6 process instances to host our 10 tabs – clearly not total isolation). And with its more granular threading model, Microsoft’s browser may hold an advantage as CPU core counts climb and customers embrace the next wave of PC platforms.

One thing’s for certain: The once sedate browser landscape just got a whole lot more interesting!


David Gerard said...

"We are so, so happy with Google Chrome," mumbled Mozilla CEO John Lilly through gritted teeth. "That most of our income is from Google has no bearing on me making this statement." -

Anonymous said...

Why don't change name Microsoft to MACROsoft

Anonymous said...

Hang on there, mojambo.

From your article: "Both products [FF and Chrome] chew-up CPU bandwidth much more aggressively than either of the IE variants..."

I don't believe any standard comparison regarding CPU utilization can be truly be "fair" as Windows (XP and Vista) are able to hide much of IE's true cpu utilization in other parts of the OS (e.g. explorer.exe).

Anonymous said...

Just one question: how was the memory usage of Chrome computed? Did you just add up the sizes of all chrome.exe processes or did you actually take into account the memory they shared too? I expect there is a sizable difference between the two.

paulm said...

How are you comparing the "working sets"?

Are you accounting for the fact that a single shared object which is only in memory once may be reported multiple times in the multi-process environment?

Anonymous said...

For anyone who wants to compare internet explorer to chrome, type in the chrome address bar:

it shows my IE7 with same tabs uses less than my chrome too

Akshay said...

The awesome part is that down the lane chrome wil help google to learn more abt browser behaviour now and . if they manage the privacy issues .. we have a winner .. they can give best suggest on earth ..

Anonymous said...

Interesting that you say Chrome is the "fattest" and that it's built for newer or upcoming machines where everyone else seem to say that it's the fastest around.

Anonymous said...

I find google chrome a very useful and fast browser as comparing to internet explorer and firefox. One thing which I have noticed on my computer is that as I use internet explorer and firefox to explore web pages my windows slow down as I open more pages but using google chrome it doesn’t happened! my windows performance increased using google's new browser CHROME I LOVE IT!

Ed Burnette said...

There's something funny with these numbers. In my testing Chrome is using less system resources than FF3 over time. Tabs within the browser and other processes on the computer are more responsive when Chrome is being used, which indicates to me that reserved private (not read-only shared) memory is better handled in Chrome. We need to do some more research.

Anonymous said...

A couple of people have asked how you came up with these memory usage numbers. Did you take into account copy-on-write and shared resources? Or just add up all the processes (which would be completely inaccurate)?

Anonymous said...


Nice post, by the way if you want to have more information about Google Chrome Easter Eggs, Secrets and the funny Google Chrome Crasher.... just check this post >>

You will have a detail description of Google Chrome.

Mike Belshe said...

Hi - thanks for the great writeup on memory comparisons. I worked a little on Google Chrome, and I just reproduced your results (for Chrome, I didn't test the others). Here are a few notes.

To measure memory, I am guessing that you are using the Windows Task Manager? On Windows XP, this measurement duplicates shared memory for each process. Multi-process browsers do get a fair amount of sharing between the processes. For single-process browsers, this is not an issue, since there is only one process :-) However, both IE8 and Chrome are a little harder to measure, because just adding the memory duplicates the same shared memory over and over. Vista's Task Manager has changed the way it measures memory; in part for this reason. You might want to run the same test on Vista, and measurements should look quite different. (Both IE8 and Google Chrome's numbers will change significantly)

If you haven't already seen Chrome's "about:memory", it will do an apples-to-apples measurement of browsers that are running. It will also give you a breakdown of where the memory goes in Chrome. I hope you find it useful.

And of course, we're still working on making the memory footprint tiny. No matter how small our footprint is, we'll always be trying to shrink it more.

Keep up the great work!

Research Staff said...


Actually, we use our own, custom agent - DMS Clarity Tracker - which employs the Windows Performance Data Helper (PDH) libraries to sample the raw perfmon counter data directly. Key values we look at include Working Set and Page File (i.e. Private) Bytes.

If you check our follow-up post you'll see that we did a quick comparison of the two values and determined that Chrome is re-using approximately 28% of its code across the various browser instances while IE 8 is re-using just 12%. So we're doing our best to be accurate while at the same time giving credit where credit is due.

For more info, check out our web site - - where you can register for a free DMS Clarity Analysis Portal account and check-out Tracker for yourself.

Anonymous said...

there are so many advantages and features with Chrome, such as it's speed, for example; now if only they would take care it's quirky cookie management...

Anonymous said...

"We are so, so happy with Google Chrome," mumbled Mozilla CEO John Lilly through gritted teeth. "That most of our income is from Google has no bearing on me making this statement." -