Sign in with
Sign up | Sign in

Meet IE8: Resource Pig

By - Source: Tom's Hardware | B 22 comments
Tags :

Microsoft’s Internet Explorer 8, released in beta form last week, might make surfing for Internet porn a little safer, but the folks at exo.performance.network report that the new browser has developed a voracious appetite for memory and CPU cycles.

There’s been widespread reporting on IE8’s InPrivate (aka “porn mode”) option that enables you to hide your browsing habits, but the new software’s resource footprint looks to be significantly larger than that of IE7, and it’s nearly twice the size of Firefox 3.01. In a test scenario consisting of 10 popular websites (including CNET, the New York Times, and Fox News) loaded into separate tabs, IE8 consumed nearly 380MB of memory. IE7 required 250MB of RAM to render the same workload, while Firefox needed just 159MB. In fact, IE8 utilizes more memory than a base install of Windows XP itself!

And IE8 isn’t just a memory pig; Microsoft’s swollen code spawned a CPU thread count that brings to mind the bed sheets at a five-star hotel: Where Firefox spawned 29 concurrent threads in the test scenario and IE7 issued 65, IE8 choked the CPU (a 2.66GHz Core2 Duo) with no fewer than 171 threads spread over six concurrent instances of iexplore.exe.

Exo’s analysis concludes that Microsoft is designing for the future, essentially counting on four and eight-core systems with 4GB of RAM to become the norm, while simultaneously creating demand for the 64-bit flavors of Windows Vista and the upcoming Windows 7.

We can think of plenty of reasons to buy rigs with more memory and beefier CPUs; running a bloated web browser isn’t one of them.

Display 22 Comments.
This thread is closed for comments
  • -2 Hide
    jhansonxi , September 2, 2008 8:38 PM
    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.
  • 4 Hide
    gamerk316 , September 2, 2008 8:53 PM
    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.
  • -2 Hide
    nukemaster , September 2, 2008 10:04 PM
    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.
  • -1 Hide
    ThreatDown , September 2, 2008 10:39 PM
    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.
  • 0 Hide
    dreamer77dd , September 3, 2008 12:01 AM
    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.
  • -4 Hide
    wrack , September 3, 2008 12:43 AM
    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.
  • -2 Hide
    jhansonxi , September 3, 2008 1:27 AM
    gamerk316jhansonxi, Firefox doesn't rely on plugins, they simply enhance what you can do.

    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.
  • 3 Hide
    DXRick , September 3, 2008 3:50 AM
    wrackDoes 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.


    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.

  • 0 Hide
    randomizer , September 3, 2008 4:29 AM
    I'll stick with my dual-core, 2GB RAM and FF3 thanks.
  • 3 Hide
    androticus , September 3, 2008 6:54 AM
    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...)
  • -3 Hide
    androticus , September 3, 2008 6:58 AM
    DXrickUh, no. Debug code does NOT use that much more resources and does NOT create threads out of thin air.


    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.
  • 3 Hide
    ossie , September 3, 2008 7:44 AM
    "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...
  • -3 Hide
    ThreatDown , September 3, 2008 1:25 PM
    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.
  • 1 Hide
    Anonymous , September 3, 2008 2:00 PM
    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.
  • -3 Hide
    Anonymous , September 3, 2008 2:30 PM

    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.
  • -2 Hide
    Anonymous , September 3, 2008 4:11 PM
    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.
  • 1 Hide
    DXRick , September 3, 2008 6:06 PM
    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.
  • 1 Hide
    Milleman , September 3, 2008 9:36 PM
    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...!
  • -2 Hide
    fuser , September 3, 2008 11:37 PM

    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?
  • 2 Hide
    Anonymous , September 4, 2008 12:39 AM
    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.
Display more comments