Don’t Wait for SP1? Mea Culpa!

Just when we thought it was safe to dismiss the conventional wisdom and recommend Windows 7 RTM for immediate deployment, along comes a last minute “showstopper” bug to make us look like fools. It appears that Microsoft missed a potentially critical flaw in its current NTFS driver stack, resulting in a massive memory leak when certain file access patterns – namely, those involved in the file data read portion of the chkdsk.exe disk check utility – are executed against a non-system NTFS partition.

The bug, which we have since confirmed in the lab, is potentially catastrophic in that it causes the offending executable – either chkdsk.exe, explorer.exe (in default Windows 7 UAC mode), or the DLL Host process (when UAC is locked down to Vista levels) - to consume all available memory and, in extreme cases, destabilize the system to the point where a “blue screen” kernel failure occurs.

Needless to say, this is a very serious bug, one that Microsoft would do well to correct ASAP via an emergency Windows Update hotfix. Regardless, the appearance of such a deep, fundamental flaw in what was supposed to be a ship-ready build of the Windows 7 code has shaken our confidence in the product. We are therefore recanting our previous recommendation that organizations skip the usual Service Pack 1 wait and instead suggest that they put all such plans on hold while we monitor this situation for a satisfactory conclusion.

As is often the case with Microsoft, prudence is still the best policy.

Read more...

Google Chrome 3.0: Obesity as a Way of Life

We received a tremendous response to our previous series of entries documenting the expansive memory requirements of today’s multi-process web browsers. At the time, Internet Explorer 8.0 had just entered its second beta release, while Chrome 1.0 was still under wraps at Google. Both proved to be massive memory hogs, requiring tens of megabytes of RAM to render each opened tab.

Eight months later, and the web browser landscape has changed dramatically. Internet Explorer 8.0 is now a shipping product and bundled with Windows 7, while Chrome 2.0 is currently Google’s latest “soft RTM” version of their nascent browser (with version 3.0 undergoing a very public beta). Meanwhile, the Mozilla folks have shipped a major update in version 3.5 – though, like its predecessors, it remains a single-process application.

Given the number of recent developments, we felt it was time to revisit our original test series and to update the data points to reflect the new “state of the art” in both browser and OS technology. Using the same set of eleven target web sites, and updating the OS (Windows 7 RTM) and browsers (Chrome 2.0.172.39, IE 8.0.7600.16385, Firefox 3.5.1) to the latest versions, we once again executed our test methodology.

Note: As before, we relied on the free tools and resources of the exo.performance.network to monitor and record system and process metrics from each test scenario.

Figure 1 – Browser Working Set (MB)

The first thing to take away from this latest data set is how Chrome 2.0 is now more RAM-efficient than IE 8.0. Previously, Chrome was slightly “fatter” than IE 8.0, at least in terms of shared code (Working Set). However, in our revised testing, Google’s browser consumed roughly 18% less RAM when rendering the same pool of web sites in a multi-tab (one site per tab) configuration.

Unfortunately, Google’s victory was short lived as the latest beta release (3.0.196.0) of Chrome 3.0 proved to be quite a bit hungrier in terms of RAM consumption. Chewing up an impressive 451MB of RAM, Chrome 3.x easily out-gobbled IE 8.0 by 5%, and topped its own immediate predecessor, Chrome 2.0, by 24%.

Figure 1 – Browser Private Bytes (MB)

Things looked even worse for Chrome 3.0 when the discussion shifted to Private (i.e. non-shared) Bytes. Here, Chrome 3.0 consumed a staggering 565MB of RAM – a half-gigabyte – while rendering our target site list. By contrast, Chrome 2.0 used just over 360MB, while IE 8.0 chewed-up 378MB to render the same sites.

Of course, we would be remiss if we failed to mention how the latest iteration of the single-process Firefox measured up to its multi-process competitors. In terms of Working Set size, Firefox consumed roughly half as much RAM as Chrome 2.0, and a third as much as Chrome 3.0. Needless to say, if you’re looking for the mainstream browser with the lightest RAM footprint, Mozilla’s Firefox 3.5 is still your best option.

Bottom Line: Google’s browser-cum-OS project has once again reset the bar for “fattest”Internet application. In its current incarnation, the Chrome 3.0 beta consumes roughly three times as much RAM as Firefox, and even outpaces the bloated IE 8.0 in the race to consume all available memory. Given the above revised data points, we can’t help but fear for any future (e.g. Chrome OS) that involves Google as the primary architect of our system software.

Read more...