Internet Explorer 8 Beta 2 arrived last week amid great expectations and some heated controversy. The latter was due to Microsoft’s decision to adopt a standards-compliant rendering model that breaks a great many IE-specific web sites.
However, while various bloggers and pundits waxed breathlessly about all of the new bells and whistles (including the much-reported “porn mode”), we were busy putting Microsoft’s new browser under the microscope of the exo.repository.
Note: For more information on the exo.performance.network, or to register for your free Analysis Portal account, visit www.xpnet.com.
Over the course of several days, we evaluated IE 8 under both Windows XP (SP3) and Vista x86 (SP1) to determine how this major update behaves and what, if any, new burdens it might place on today’s over-taxed (in the case of Vista) Windows PCs.
What we found was another example of unchecked Microsoft code “bloat,” complete with “shirt-bursting, waistline-stretching” memory consumption and the kind of CPU-hogging thread growth normally reserved for massively parallel server farms.
For example, on our Dell OptiPlex 745 (Core 2 Duo @ 2.66GHz) Vista/XP test bed with 2GB of RAM, IE 8 consumed just under 380MB of memory during a 10-site, multi-tab browsing scenario of popular general media, technical media and humor-related Web destinations (see bottom of this article for a list of sites).
By contrast, IE 7 consumed just under 250MB rendering this same workload, while Firefox 3.01 put both IE versions to shame by completing the same browsing scenario in just 159MB of RAM.
Figure 1 – Peak Browser Working Set Under XP/Vista
The story gets worse for IE 8 when you examine the number of threads spawned to complete the scenarios. Under Firefox, the count never exceed 29 concurrent threads. IE 7 spawned a hefty 65 execution threads, while IE 8 tried to choke the life out of the CPU with a massive 171 concurrent threads.
By comparison, the instance of Microsoft SQL Server 2005 x64 Edition that hosts the exo.repository rarely spins more than 100 concurrent threads – this on an 8-way, 8GB server machine servicing over 3000 actively monitored PCs.
Figure 2 – Peak Browser Thread Count Under XP/Vista
One area where IE 8 came out ahead of Firefox is in overall CPU utilization. Firefox consumed an average 33% Processor Time under XP (48% under Vista), while IE 8 took-up 22% of the CPU (33% under Vista) and IE 7 was the least aggressive at 13% (24% under Vista).
Considering how much faster Firefox is than IE 7/8 at displaying most web sites, the additional CPU cycles are understandable and likely attributable to a more efficient rendering engine employing fewer threads in exchange for faster linear performance.
Some observations:
- With a massive working set approaching 20% of our test bed’s 2GB RAM configuration, IE 8 may be the long awaited “killer app” that drives customers towards 4GB+ systems and the 64-bit flavors of Windows Vista/7.
- By greatly increasing the number of concurrent execution threads, and then spreading them out across multiple, discrete processes (in our case, 6 separate instances of iexplore.exe), Microsoft seems to be positioning IE 8 to take advantage of the greatly expanded core counts of future Intel and AMD CPUs – at the cost of overwhelming today’s single and dual-core PCs.
- By delivering superior performance while maintaining a nearly 2x smaller memory and CPU footprint across the board, Firefox 3.01 proves once again that the open source community can often trump even the most well-funded commercial projects when it comes to delivering efficient, streamlined code.
Bottom Line: No matter how you slice the data, IE 8 represents a massive expansion of the baseline runtime requirements for Microsoft’s Internet Explorer web browser. Meanwhile, the Firefox folks continue to embarrass Microsoft by “doing it better” (including delivering superior performance and overall standards compliance) while consuming fewer hardware resources. How these efficiencies will play in the aforementioned multi-core future remains to be seen.
It may be that Microsoft’s focus on parallelism will reap dividends once the hardware catches up with the software - much like Vista has looked better as the Windows PC ecosystem has evolved to support its epically porcine girth. Such massively-threaded products will likely feel more at home on the 4, 8 and 16-core systems of tomorrow, but for right now they represent the worst kind of code bloat.
List of web sites visited as part of our test scenario:
- www.cnet.com
- www.news.com
- www.infoworld.com
- www.zdnet.com
- www.nytimes.com
- www.foxnews.com
- www.boston.com
- channel9.msdn.com
- www.dilbert.com
- www.arstechnica.com
- www.palmbeachpost.com
Note: To ensure an accurate, rich-media experience, we installed both the Adobe Flash 9 and Microsoft SilverLight 2.0 (Beta) plug-ins under each tested browser/OS combination.
Posts
27 comments:
Were all of the 171 threads doing work, or were they idle? If they're idle, they don't hog the CPU, they just sit there.
Could some of the bloat could be due to debugging code? It will be interesting to see this study done against production level code.
IE is just like Steve Balmer, a fat crazy piece of ... stuff. They can't get anything right simple because what is right for the consumer is not right for MSFT. What is right for MSFT is to push for upgrades... so eating that extra 20 burgers is ok, we just loose the belt a little bit (again!).
How can one conclude that concurrent threads hog the CPU and then show that IE8 uses LESS CPU usage in the following paragraph?
That clearly shows the authors lack of understanding in how things work. Thread switching has some CPU overhead, but one can't just assume more threads = more CPU usage.
Also when compared to firefox, more RAM, less CPU usage... seems like a very common trade off where I come from. How about pointing that out or creating a RAM used/CPU% metric that would likely be a better measure.
Good all around if you ask me.
This is such biased, ridiculous nonsense. First of all, it's a beta product. That debugging code uses a *MASSIVE* amount of memory, slows things down considerably, and isn't representitive at all of the final product.
Second of all, where do you get that "Vista is 40% slower no matter what you do" notion from? Anyone who's actually used the system for a substantial amount of time knows that, with decent, modern hardware, Vista flies faster than XP ever did. A 3 year old dual core with 3 year old memory and a 3 year old graphics card will more than suffice for such an experience. Heck, even games run as fast on Vista as they do on XP, sometimes even faster, thanks to NVIDIA's and ATI's drivers not sucking anymore, and thanks to Vista SP1:
http://www.extremetech.com/article2/0,2845,2302500,00.asp
All this is, is useless, unsubstantiated, ignorantly formed and terribly biased opinions of a company's products that you clearly don't care to give a fair chance to. Opinions which you try to back up with misinformation garnered by the earliest version of Vista when 3rd party drivers were still terrible, and that he hasn't bothered to re-check in over a year, staying perfectly happy with buying into whatever FUD those Apple commercials will feed you.
er..where did you get your figures from.
I opened all the sites on your list, plus some of my own - so a total of 15 tabs and I've got a 5 iexplore.exe processes totalling 194 meg of memory used. I haven't bothered to check the threads but still it isn't 380 meg.
Can you update this article to include results from Google Chrome?
I also agree with a previous poster - I don't get anywhere near 380MB mem usage under a similar situation. Are you testing on a clean machine with NO browser plugins installed?
Missing Opera and IE6
Nick,
Perfmon doesn't lie. Our Tracker agent usese the Windows Performance Data Helper (PDH) library to sample the same counters that Task Manager, Perfmon, etc., sample.
Bottom Line: After visiting those 10 sites, each in its own tab, IE 8 under Vista SP1 had gobbled-up nearly 380MB of RAM (\Process\Working Set).
If it makes you feel better, Chrome is grabbing nearly as much, and actually exceeds IE 8 on average, when rendering those same 10 sites. See our most recent post in this blog for details.
Note: The only plugins installed were Adobe Flash 9 and Microsoft Silverlight 2.0 Beta 2.
You are completely off base here, I am running Beta 2 of IE 8 and with 20 tabs open I top out at 200MB and that is throwing in some YouTube pages.
Now lets look at FF3.0.1
Opening up the browser on its own pulls a whoppoing 30MB just to start it up to match my 200MB usage in IE8 only had to open up 15 tabs..
Seriously missinformed FUD going on here
Perfmon doesn't lie...and neither do I (we)... :-)
Evidently you do not know what WorkingSet is. On Windows, workingset is the amount of phyisical memory that is mapped to a process. This includes the dlls. So, when IE8 starts a new process for each tab, the same code (dll) memory is mapped into each process. Therefore, if you have 5 MB of shared code & it is mapped into 10 different processes, by your count you have consumed 50MB of memory, when in fact it is only 5MB. This is also why Chrome is registering so high, it too uses a new process for each tab. Please understand the core architecture and how to measure it before you pass judgement.
I suggest you pick up a copy of Windows Internals so you can understand the different memory metrics you are using. As anonymous said above, your data is counting the same shared memory pages multiple times. In addition to the shared pages in DLLs there are also mapped files and page file backed sections that can be shared, both of which IE 7 and 8 use extensively.
http://msdn.microsoft.com/en-us/library/ms684891(VS.85).aspx
Process Working Set
The working set of a program is a collection of those pages in its virtual address space that have been recently referenced. It includes both shared and private data. The shared data includes pages that contain all instructions your application executes, including those in your DLLs and the system DLLs.
Does the "research staff" want to comment on how they calculated the "Fatter" memory usage?
To everyone criticizing our use of Process\Working Set to size the browser memory footprints: Please see our follow-up post in this same blog site.
May I suggest a better metric for memory usage? --> In a virtualbox with limited memory, disable the page file, reboot, open the browser, and load pages in tabs until the OS runs out of memory and crashes. Report the number of tabs.
There will be no interpretation necessary about how working-set memory works.
You guys wouldn't have to worry about any of this if you'd just use the almighty Opera.
You meant to say "waxed breathless"...
Two thing guys.
One: More RAM usage isn't bad. (sounds strange.) You can't do anything with empty RAM. That is why Vista is faster than XP! Vista actually uses the resources it has.
Two: I am running IE 8 beta 2 right now on a 360MHz Pentium 3 on 256MB of RAM. IE 8 is actually faster than IE 7. It is very responsive. I can do other things as well and still have RAM left over.
Hmm.. I'm running IE 8 beta 2 and Chrome and FF 3, all on Vista.
The fattest instance of IE 8 is using 20 MB of RAM, where there are two instances of Chrome consuming more than that.
At work, I make heavy use of XSL, and I have noticed Chrome taking nearly twice as long to process some pages as compared to IE 8.
So, I'm not sure that I agree with this article.
One last thing. I have noticed that Firefox and IE 8 (beta 2) are roughly even in resource consumption, except when hitting Flash-based sites. Flash sites seem to really do IE 8 in, regarding resources.
As far as features go, though, I'm sticking with Chrome for now.
I wasn´t even able to install IE8 beta, because of a missing update, that I have already installed. Thats ridiculous. I use FF3.0.1 and am abundantly satisfied. Anyway usability issues play a major role also, and here it´s up to the users to decide which product they like the most. As far as I am concerned I can´t bear any microsoft product exept of xp and office.
I think you guys messed something up in your testing.
I check a group of deal sites a couple times a week… There are 12 sites.
IE8 Beta 2: 3 processes, 161mb.
Firefox 3: 1 process, 85mb total.
Chrome Beta: 14 processes, 149mb total.
I checked the same 10 sites you used in your test and found:
IE8 Beta 2: 6 processes, 256mb total.
Firefox 3: 1 process, 133mb total.
Chrome Beta: 13 processes, 197mb total.
Can you believe this? I've just loaded up IE* beta,
went to the google page, found out it was SUPER slow, did Ctrl-Alt-Del found out it was taking up exactly 1,882,273k Mem Usage!
I don't want to say anything specific.It's just that IE8 should be introducted as a Beta Version and complaints of slower perfomance and experience compared to other browsers and it's own previous versions etc, IE7,IE6 and so on.
Well what choice do we have if each microsoft windows is pre installed with a version of IE??
not much plus only those that frequently use the internet will complain about this.Just Opening so many tabs at an instance also doesn't help.
Hahahahaha..... Threads idle or not idle, beta code vs. release code what does it matter? M$ just can't release a stable first release of anything. Beta testing is now long gone and the current release of I.E. 8 sucks just as bad, if not worse than the Beta version. I.E. 8 on it's own almost consumes more resources than the bloated OS can. The only solution is to install Firefox and never open I.E. at all.
I wish I could say otherwise but for M$ it's all about how pretty they can make their software look to yet again get the consumer left without much choice but to buy M$ software. All about the money.
M$ has proven themselves in this regard for well over a 15 years now, but hey, as a Company (Monopoly) it sure works otherwise we as the consumer wouldn't have made MR. Gates so rich!
Post a Comment