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 exo.performance.network, or to register for your free Analysis Portal account, visit www.xpnet.com.
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 Mozilla.org 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!
Read more...
Posts
