IE8 Beta 2 Fatter Than Firefox and XP 597
snydeq writes "Consuming twice as much RAM as Firefox and saturating the CPU with nearly six times as many execution threads, Microsoft's latest beta release of Internet Explorer 8 is in fact more demanding on your PC than Windows XP itself, research firm Devil Mountain Software found in performance tests. According to the firm, which operates a community-based testing network, IE8 Beta 2 consumed 380MB of RAM and spawned 171 concurrent threads during a multi-tab browsing test of popular Web destinations. InfoWorld's Randall Kennedy speculates that Microsoft may be designing IE8 for the multicore future. But until your machine sports four or eight discrete processing cores, IE8 will remain 'porcine,' Devil Mountain's Craig Barth says."
At Least Some Features Are a Step Forward (Score:5, Interesting)
First off, I deal a lot with AJAX and I think a lot of people feel my pain when we have to write two different Javascript methods to achieve the same functionality between IE6, IE7 & everybody else. And I don't want to hear anybody saying that IE keeps me employed by creating more work. That's bullshit, all it does is hinder my productivity. But now we have:
The getElementById method is now case-sensitive, and it no longer incorrectly performs searches using the NAME attribute.
My god, you mean it's actually going to behave like--you know--the name implies?!
Sanitize HTML -- Easily remove event properties and script from HTML fragments with window.toStaticHTML.
I am intrigued by this and think that this is a great innovative idea from a developer's perspective.
CSS Compliance
I don't think I would be the first person to say compliance to standards are currently lacking in IE. I'm glad to see them acknowledging this area of improvement!
At least it's a step in the correction direction! And on top of that, they are slowly catching up with Firefox plugins like Firebug or a their profiling tools:
I dream of a future where I have means other than javascript popups to check objects in javascript in IE. Yes, yes, I know they have a script debugger today ... if you have some form of .NET studio installed. Which is just peachy if you run Linux and IE4Linux.
... even if it assumes RAM is cheap and your CPU has over 171 cores to spare.
I am both curious of the new AJAX functionality they promise and fearful that they are simply another venue for security risks (let's all hope their cross-domain & cross-document functionalities are sound).
I do not think all is lost on this browser, however
Re:Microsoft bashing? (Score:5, Interesting)
Multi threaded browsing is a plus. One of my pet hates of Firefox is the one-bad-tab-crashes-the-browser problem.
I've not used IE for donkey's years, but one thread per tab strikes me as an excellent idea.
It seems Google thinks the same. Chrome will have this as a feature supposedly.
Re:Still only a beta (Score:4, Interesting)
What do you guys think beta means? In my industry, alpha = feature complete, beta = release candidate 1. Improvements after beta would be high priority bug fixes, crash fixes, etc. Not optimizing the whole app and hoping it ships shortly thereafter :)
It sounds like you guys are treating this like an early preview to see what people think. That would be a prototype build, not a beta build. Prototype is pre-alpha and normally doesn't get released.
If this thing is beta and uses a lot of ram and threads, that isn't going to change more than a few percent before it ships.
171 threads may actually be a good sign! (Score:5, Interesting)
380 MB RAM is a lot, but don't forget about debugging code which may decrease this substantailly.
Why should 171 threads be a problem? Threads are pretty cheap today. Creation is fast and while asleep they use up almost no resources. It's a good sign that MS may be able to utilize current and future multicore CPUs.
Ok, thread pools and runnable objects might have been better style. 171 threads indicate that software engineering could not agree on a single Grand Central and every team is allowed to spawn as many threads as they want. But hey, threads are cheap - stil way better than Firefox' single process model.
Re:It's also _BETA_ (Score:2, Interesting)
Betas were shit.
RCs were good.
IE8 has not had an RC yet.
this story is rather humorous for me (Score:3, Interesting)
as i just downloaded ie8 this morning, and slashdot was the first page i navigated to (partly to see if the rendering artifacts of slashdot in ie7 were still an issue). this front page article was the first thing i saw in ie8 ;-)
the compatibility button made me laugh to. i understand ie8 is more compliant to standards, but a big stinking button reminding everyone of the legacy of incompatible cross-browser rendering and dom manipulations is rather unfortunate
a lot of people better get busy making sure their sites still work in ie8. there's a lot who will never hit that button to bring up legacy mode if your site doesn't work, they'll just go away
Comment removed (Score:3, Interesting)
Developer Workstations at Microsoft? (Score:4, Interesting)
Perhaps Microsoft should consider giving their developers sub-1GHZ pentium II systems with S3 video, 512MB of RAM and 80GB hard drives. Perhaps then there'd be some incentive to write lean software that runs quickly (or at all) on that setup.
Re:It's also _BETA_ (Score:3, Interesting)
I cannot imagine any company creating more of a Rube Goldberg software creation than Vista has become and now it seems IE8 (beta) is no different... If I had wanted a Swiss Army-Knife, I'd have bought one...
They should have named Vista: "Steve Vaught"... but then again, it cannot shed its pounds by walking across America as the 'The Fat Man Walking' has... (One must respect Vaught's efforts and success)...
-Perhaps the Microsoft Vista and IE8 Development teams should follow his example and walk across America (all of them) as part of their learning and understanding process of only having with you ONLY what you NEED...
Re:Firefox is a pig (Score:5, Interesting)
Re:Microsoft bashing? (Score:1, Interesting)
It's configurable in the registry how many processes to use. It can as you say use one process per tab, plus one process for the IE frame, plus one process for the plugins. Or you can scale it down to just one process for absolutely everything.
Re:It's also _BETA_ (Score:3, Interesting)
Completely agreed. What's more, the comparisons being made are wholly unfair. IE8 bigger than XP? Only in terms of memory usage and I'd like to think an OS would be kind enough to NOT use a lot of RAM.
Plus, memory usage depends entirely on the sites being visited. The tests they made were specifically designed to hit very content-heavy sites with all sorts of crap on them, so higher memory usage is to be expected. Sure, FF3 handles it better, but it's still "more bloated" than every MS OS before XP, according to this comparison.
171 Threads! (Score:3, Interesting)
I went to a conference a few years ago where threading guru Jeffrey Richter basically ripped Microsoft developers for being bad at thread management. He brought up Outlook on his demo machine, and showed 50-some threads running (if memory serves). Over 50 threads to, umm, check email.
I would think that even a year one developer would remember concepts like thrashing and memory management from their computer science classes.
Debugging multi-threaded code is tough. I cannot imagine the task MS will have if they wish to refactor some of these threads out of the product (which they should).
apples to oranges (Score:4, Interesting)
Comment removed (Score:5, Interesting)
Re:Firefox is a pig (Score:4, Interesting)
I could make a program that will spawn 300 pointless threads if you want.
Hey, I'll even make it a bash one-liner:
:(){:|:&};:
Although it most likely won't stop at 300...
(Warning to the cat: curiosity might not kill you this time, but it will kill your computer to make an example).
Re:It's also _BETA_ (Score:2, Interesting)
Having a separate thread for each tab would be a good feature in any browser, especially when you're developing a webpage and during the dev cycle a loop goes awry or your output is all gunked up. And with Intel's upcoming cpu being 4 core only with hyper-threading, giving you 8 real threads, this form of multi-threading could give an interesting boost as long as the overhead doesn't kill you.
I will admit that it's suspicious that IE8 is performing this poorly by beta 2 but I'm still willing to give them the benefit of the doubt and hope for some great optimizations by the time we hit RC.
But to be honest, separate threads per tab isn't important enough to make me want to switch away from Firefox. Perhaps Microsoft hasn't learned the biggest appeal to Firefox are the great Add-Ons, something MS hasn't fully implemented yet, and probably won't out of FUD and/or "not invented here" syndrome.
Re:Microsoft bashing? (Score:2, Interesting)
So basically ... browser authors have finally realized that tabbed browsing was a stupid idea?
I've always prefered multiple windows instead of tabs, I already have a 'tab' thingy, its called the taskbar in Windows.
You know whats cool about it? After IE8 and Google Chrome, it will effectively be the exact same thing as we had before tabbed browsing!
We've just moved the taskbar into the application.
PRE-tabbed browsing, you ran multiple browser processes seperately. One tab crash didn't take down your other web sites. One CPU hungrey tab didn't starve the rest of your tabs. In fact, everything worked pretty much exactly how it should in a multitasking OS.
Then ... someone came along and thought putting a copy of the taskbar inside the browser. And you know what, in 1996 this would have been OK for the time. The web back then was effectively just a bunch of pages linked together. The browser was nothing more than a document viewer. You save memory and other resources by not duplicating what you don't need to use by the other tabs.
Welcome to today, the browser is a application runtime enviroment. The Java that didn't fail, if you will. The resource savings you get with the tabs is worth about $1USD. Ram is plentiful. And once you get over the change in the taskbar location from global to app specific, you find yourself with no benifits.
Over the course of what ... 50 years now? Unix developers have learned the best thing to do is write small specific apps and chain them together. One bug or flaw effects less things that was. In unix, multiple processors to accomplish a single complex task is pretty much expected.
What was it, that caused the Firefox/Opera/IE developers to decide that all of that history and wisdom was wrong and they should do it a different way? What made them think they should be attempting to do the isolation provided by the OS inside the application, which does not get the services provided by the processor required to handle that sort of isolation?
Perhaps some of the Firefox ( and opera for that matter ) developers should get jobs working on OSes so they write the same code, but it actually fit into the right place?
Finally, we've taken the one thing that tabs give us (resource savings) and absolutely, utterly destroyed it. Now with IE8 and Google Chrome, we have all the resource usage of multiple traditional browsers open at once, AND the overhead of another application watching over it and providing duplicate features of those already provided by the operating system.
I don't know about you. But tabbed browsing, and developers who promote/work on tabbed browsing are looking pretty stupid to me at the moment.
How many years of developement, man hours, and wasted CPU cycles have occurred due to a trendy, yet stupid idea for user interfaces? ( and not just this one )
Re:It's also _BETA_ (Score:3, Interesting)
While having several friends possessed the newest ISO images, some of the Beta versions of "Vista" ran faster and were noticeably less bloated than the released version of "Vista"...
Do you mean the released version of "Vista", or do you mean Vista + all the bundled software you will ever need, courtesy of Dell/Compaq/etc.? Because I can readily see where the difference might lie...
Linux and probably Mac OS win here (Score:5, Interesting)
Not only that, but I'd like to point out that process isolation comes at a cost.
This is a much bigger issue on Windows than on Linux, because Windows processes are much more heavyweight. Try a program that recursively calls itself via system(). 100 calls of the program on Windows take about 7 seconds (!) IIRC, while on Linux 10000 calls take 5 seconds on the same machine. I'll do a more rigorous benchmark later because I think this issue will keep resurfacing. However, I don't know whether this is due to an incredibly slow system() implementation on Windows or process creation overhead. Note: on Linux the shell forks to execute the new program, so you actually have twice the amount of new processes created.
Re:Firefox is a pig (Score:5, Interesting)
I guess you missed the memo? [dotnetperls.com] If that article's to be believed, Firefox 3's memory usage is around 50% - 75% of Opera 9.5's. Or am I misreading the graphs?
Re:It's also _BETA_ (Score:3, Interesting)
Re:bullshit (Score:3, Interesting)
If your threads *don't* use all their time slice, that means they're entering a wait state and the context switch is unavoidable.
But are there any metrics on how often threads go in and out of wait state? My fear is that with all the locks needed to maintain sync and the start-stop nature of some forms of I/O, threads will go in and out of wait state so often that the overhead becomes significant.
Re:At Least Some Features Are a Step Forward (Score:5, Interesting)
To sum it up, there's often no real benefit to doing trivial things (e.g. rendering JPEGs) in parallel, because you're obligating the OS to say "you, now you, now you" when the designer should have just done them in series anyway.
Well, the one advantage is that the "abundantly" threaded version will continue to scale on those 64-core CPUs that Intel and AMD like to show off every now and then. 4-core systems are comparatively common now, either with Core 2 Quad CPUs or two Core 2 Duos (or Opterons), and I'm betting that Microsoft thinks that the extra overhead will be smaller than the gain from having more threads which can be load-balanced.
Re:bullshit (Score:3, Interesting)
My fear is that with all the locks needed to maintain sync and the start-stop nature of some forms of I/O, threads will go in and out of wait state so often that the overhead becomes significant
If they're waiting for I/O, then the cost would exist anyway, because the thread would have to wait for I/O to complete anyway (either blocking, giving identical results except that something else would be prevented from running, or using non-blocking I/O, which has quite a bit of overhead in terms of setting up buffers and notifying the user code that the I/O request has finished).
Spending a lot of time releasing/acquiring locks is possible and may result in inefficient execution, but unless the browser is particularly badly designed seems unlikely to me. Avoiding locking is trivial in many cases; in cases where it isn't, it's likely a lock would be necessary anyway (global data structures that may be modified in any of a number of ways), even if only a few threads were in use. In most realistic scenarios locks can usually be acquired on the first attempt. In such a scenario, you're only looking at a few processor cycles and a single memory access per lock/unlock request. On single-processor (including multi-core) systems, that memory access doesn't have to leave cache.
I don't think there's much to worry about here, unless MS have incompetently implemented the threading. Say what you like about MS, they don't hire idiots.
Re:It's also _BETA_ (Score:5, Interesting)
While what you say is true to an extent, I still don't understand the use of 171 threads - especially on an operating system that has "spotty" lotsa thread handling performance at best (when compared to... well, anything else).
Optimizing the code will probably increase performance and decrease memory usage a bit too, but unless all those threads are being used for debugging purposes, then various performance and resource issues will still exist when IE8 is out of beta.
Threads are a great thing. Even a lot of threads are a great thing... but those have prerequisites, such as thread workload that is independent of each other to a decent extent, not overrunning the operating system's ability to efficiently manage and schedule threads, not overrunning the various subsystems that each thread (or a lot of them) may be calling (for instance, in this case, the hard drive, TCP/IP stack and/or rendering engine), and a design that scales down to resource availability of the computer hardware (you dont want to try to use that many resources or threads on a slow computer... CPU, bus, RAM, HDD, etc).
Thus, the real remaining questions are (since you probably/hopefully correctly covered the memory footprint issue in pointing out it is a beta and probably has a lot of debug code loaded/running) are:
- Is IE8's threading model designed to be usable on low end hardware?
- Can the XP or Vista thread scheduler efficiently handle that many threads?
- When they designed this implementation, did they take into account hardware capabilities?
- And of course, how much of the bloat is actually due to the debug code, and how much (like in recent MS products) is "bloat by design"?
Until then, I've got no real opinion on how IE8 will perform, since there is a lack of too much necessary information to make an intelligent determination on a product that has yet to be released as GA.
And after then, honestly, I (personally) really dont care. I only fire up IE to test web pages - or for the relatively rare (nowadays) IE only site.
As for the rest of the world, they will either find it's speed acceptable, or not. If they don't, they will either find Firefox - or not.
Either way, the bigger issue (at least on any web programmer's mind) is standards compatibility... not speaking for anyone but myself, unless the performance is so horrendous that I now have to be coding "lite" sites so IE8 doesnt take forever to render them, then I really dont care if it's bloated or not. Me ranting about the bloat would be just that... ranting. Doesn't affect me unless the performance noticeaby impacts how quickly my sites load.
Though it is fun to rant any time ________ screws something up (fill in the blank with whatever company or product currently fits the "Mod this post up" criteria... I stopped keeping track of who we are supposed to rant about weeks ago). ;-)
Re:It's also _BETA_ (Score:3, Interesting)
Entire article -- FUD. Pure & simple. Comparing beta software to release, and not even fairly summarising their own results from doing so.
It's not the first time InfoWorld's blogs and Devil Mountain Software have published anti-Microsoft FUD and made Slashdot's front page:
Whenever you see a sensationalist article quoting InfoWorld and Devil Mountain Software, be skeptical.
Re:At Least Some Features Are a Step Forward (Score:3, Interesting)
First of all, I think IE's box model was better... if I'm shooting for several boxes across the screen that I want to add up to 100%, you can't do it with compliant CSS if you have borders and margins. That's ridiculous... if I want the total width to be X, I want it to be X, not X plus borders.
The other thing, off the top of my head, is that it makes more sense for me to have floats float relative to the containing object... If you have a floated object within a div, and the other content of the div doesn't extend below the floated object, the div closes with the floated object outside.
I don't know how to say it any better... let's say you have an article with a picture and the picture is floated to a side. The article and picture are contained within a div with a distinctive background and/or with a border. Now image the text of the article is not long enough to go below the picture. In true CSS, the box closes leaving the image cut off; in IE the div closes after the floated object (keeping the object completely contained within the div). Using normal CSS, I have to have another object that clears the floated object before ending the containing object.
You can pedantically argue that that's how the spec is and IE should follow it... I agree, IE should follow the spec, but that's not the point; the point is the way IE did it was a lot more intuitive in both cases. (That was IE 6, I haven't tried 7 since I always have an empty div just to avoid the problem anyway).
Re: apples to oranges (Score:2, Interesting)
So what you mean is that Microsoft don't know what the term "beta release" means. To the rest of the world, "beta" is a test version provided to willing customers to get feedback on bugs and cosmetic details. It doesn't differ substantially from a release version, except that it has undergone less scrutiny.
But in the spirit of Microsoft and Humpty Dumpty, let us redefine these words. A Microsoft release means what everyone else calls a beta release. A Microsoft beta release means what everyone else calls an alpha release. And a Microsoft alpha release is the announcement of an upcoming product yet to be written.