It's still beta (which is effectively an alpha for the rest of the industry) so wait until the first major post-release update before evaluating it.

Firefox eats up a lot of memory also. Since some browsers rely on add-ons more than others I would like to see a comparison of equivalent feature sets including add-ons and plug-ins, especially the tabbed UI, Flash, Adobe Reader, and Java.

jhansonxi, Firefox doesn't rely on plugins, they simply enhance what you can do. Besides, those plugins aren't loaded into memory if they aren't used.

Also note: IE8 looks to be CPU intensive, due to each tab needing to be tracked individually. I doubt this will imrpove much (i expected this as well), so i'll stick with Firefox, thanks.

BETA.

May need more ram if it keeps all data in memory to make it easy to fully clear when done.

With the way computers get faster so often, it may not be an issue for long. Kind of like how a high flash site brings a XP 3100+ to its knees yet uses less then 10% on a modern system.

Googles chrome browser doe the same thing and uses even more processes, firefox is also going to move to this in ff4. It keeps one tab from crashing the whole browser or a plugin from crashing the whole browser.

I think it a great that software is starting use eight-core and a lot of ram and 64bit. I just don't think that you should need to buy I super computer to run a browser as this should be basic software. I think it should adapt it's self to whatever is inside your computer to a point. 8 cores, 4 gigs of ram, sounds like it should do something amazing. makes you wonder.

Does anyone doing this testing actually knows how a software is developed! It is in BETA and therefore there is a lot of debug code and optimizations turned off. This simply means more resources. Wait until most of the debug code is taken out and optimizations done and then test you morons.

People would do anything to get a higher page visits.

Some of IE8's tab behavior can only be duplicated in the current versions of Firefox using add-ons. Basically I just want them to be configured as similarly as possible when compared to eliminating whining about bias.

Uh, no. Debug code does NOT use that much more resources and does NOT create threads out of thin air. Once optimized, it will have a smaller footprint and be faster, but that has nothing to do with CPU utilization and the number of threads running.

Most of the debug code is extra error handling to catch bugs, which (obviously) is not executed unless a bug is encountered. The rest is break points added for tracing, which adds to its girth.

So, running IE8 on Vista will require oct-cores and 8 gigs of RAM.
I will stick with FireFox.

I'll stick with my dual-core, 2GB RAM and FF3 thanks.

OMG! They are doing it again... previously, they would design their OS and apps so that they were barely tolerable by the end of the hardware cycle in which they were released. Now, they are doing this with processes/threads -- assuming a 16 core/32 thread CPU for "best" performance... (well, I exaggerate a bit... but with MS, you really can only ever exaggerate just a bit, no matter how you try to exaggerate big...)

Uh... the first part is just not true. Especially MSVC, in debug mode, there is horrendous additional overhead for each memory block, so it does add considerable to the memory bloat. It also kills performance -- one of our metacompilers ran something like 10x slower in debug mode (it was very memory allocation intensive.) General code that is not so memory intensive (doesn't make tons of little allocations) is probably hit less, but I would suspect that something like a Javascript interpreter, and frankly probably lots of browser code, is fairly allocation intensive.

"It's still beta": the typical excuse for what "is effectively an alpha for the rest of the industry".
Actually everything m$ throws at us, and cashes in big time, is "beta" (at least for the rest of the industry), bloated and buggy, and needs at least a few years/service packs to work decently, if they can be persuaded to fix it: "... wait until the first major post-release update before evaluating it."
Next time please don't speak in code...

I run ie8 flawlessly on a single core 3200+ I don't know what crack you guys are smoking, it's no slower than IE7.

Its rumored in FF4 there's going to be a choice of whether to run in CPU-Intensive mode (each tab with its own process) or with all the tabs in one process like they currently are in FF3 and below. I'm currently using FF3 and have no complaints. I'm going to stick with FF3 and update it as new versions come out. Besides, both are just browsers and a free ones at that, use one that works to your liking and stick with it.

Actually debug code is much much larger than a slim release build. It also depends on the type of linking used. If wish to see faster link times (which is what is desired in a debug build as compile times are not even 1/10 the time it takes to link as compilers will only compile what has changed, while a linker requires all compiled modules to be combined into a binary) it requires that all linker files be independant of each other and can bloat the binary 2-4x the release build size. All of this must be loaded into RAM when the binary runs, so yes, a debug build can consume many many more resources. If you want to see this bloat for yourself, build a large app with incremental build on/off and you'll see a massive difference.

We're creating softwares with future-aware. Don't worry if it run really slow now, next year your new PC will be equip with 10-processors cores and 8Gb RAM, the software will run much faster then.

I was referring to the number of threads and CPU utilization. It doesn't make sense for them to release a beta version that was compiled in debug mode. The purpose of debug mode is to enable the programmer to run the program within Visual Studio (with the source code), where they can trace it, set break points, and monitor things as it runs.

But, if the beta version was compiled in debug mode (for user testing) it would use more memory and run slower due to all of the extra code.

Thread count is not a meaningful metric to measure the performance of a piece of software... it makes the author sound like he/she has an axe to grind. Want to compare performance?... look at processing time, processor and memory utilization for identical workloads. For GUI tasks measure the responsiveness of the application to user input. For Browsers measure processor utilization with 1 tab, 10 tabs, 100 tabs open. ANY of the above measures would tell you far more than a thread count number... which tells you basically NOTHING (except that IE8 MAY scale better than it's competitors... of course then again... it may not).

My God...!

Why does the OS and especially internet browsers require specifications that more or less are equal to mini supercomputers? All I do on the internet is to read news, articles, check mail etc. So how do I benefit from using a resource heavy browser? Do the articles look better?
It's just so silly...!

1) It's BETA!

2) You can buy an extra 1GB of RAM for the price of a movie ticket. Who cares if 380MB of RAM are required to load up 8 sites at one time?

Fuser wrote: "Who cares if 380MB of RAM are required to load up 8 sites at one time?"

Well, I do. First, because it's evidence of embarrassingly bad coding. That equals over 40Mb used for each web page. What on earth is the software doing with that RAM? It's like watching a guy paint a house with a broom. I guess I don't care if it's not my house, but I have enough pride in my work that I feel sorry for the guy. And I certainly wouldn't buy what he's selling.

Second, like most people I typically have many programs running. If each took 320MB I would run out of ram on the XP (3BG) or Vista (4 GB) limits. I'm not going to switch to 64 bit OS with all the driver and other problems just for the privilege of running a new browser.

Third, RAM pigs usually are CPU pigs too. From these tests it appears that IE8 is no exception. I like my programs to run fast. Maybe you don't care. That's fine. To each his own.

Fourth, big bloated programs typically have more security problems. If the coders write that poorly then they likely haven't found all the holes. MSFT's history and reputation are well-deserved in this area.

Fifth, and most important: what feature of IE8 would compel me to use it? All purchases are a cost benefit analysis. Is there some feature or benefit that overcomes IE8 being a slow piggy program? It's just a browser for god's sake. Does it render pages better/faster/cheaper than FF/Opera? No, no and no.

@Marcp1:

Well, I suspect it's because each browser tab is running in isolation, so it needs it's own heap and stack space. And, again, it's beta.

Regarding the CPU utilization, IE8 outperformed FF3:

"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)."

But please, don't let me interrupt your MS hating.

http://exo-blog.blogspot.com/2008/ [...] -than.html

oh, and they were using incorrect procedures for measuring memory usage. Here is their corrected data:

http://exo-blog.blogspot.com/2008/ [...] ow-up.html