Slashdot Mirror
Chrome Vs. IE 8
snydeq writes "Google Chrome and Internet Explorer 8 herald a new, resource-intensive era in Web browsing, one sure to shift our conception of acceptable minimum system requirements, InfoWorld's Randall Kennedy concludes in his head-to-head comparison of the recently announced multi-process, tabbed browsers. Whereas single-process browsers such as Firefox aim for lean, efficient browsing experiences, Chrome and IE 8 are all about delivering a robust platform for reliably running multiple Web apps in a tabbed format in answer to the Web's evolving needs. To do this, Chrome takes a 'purist' approach, launching multiple, discrete processes to isolate and protect each tab's contents. IE 8, on the other hand, goes hybrid, creating multiple instances of the iexplore.exe process without specifically assigning each tab to its own instance. 'Google's purist approach will ultimately prove more robust,' Kennedy argues, 'but at a cost in terms of resource consumption.' At what cost? Kennedy's comparison found Chrome 'out-bloated' IE 8, consuming an average of 267MB vs. IE 8's 211MB. This, and recent indications that IE 8 itself consumes more resources than XP, surely announce a new, very demanding era in Web-centric computing."
Acid 3 Test, IE8: 14/100 Chrome: 78/100 Enough said. IE8 is another pathetic attempt at a good browser. As a web designer and developer I can tell you I look forward to mass acceptance of the final version of Chrome. Under no circumstances do I EVER expect to look forward to IE, any version.
Just because something takes up more resources doesn't mean it has to be slower. Granted, something that takes less resources usually runs faster, but a good application that makes good use of RAM and CPU power can seem fast.
Taxation is legalized theft, no more, no less.
The article mentioned in the summary states that IE8 (beta) consumes more resources than XP, not Vista. That's quite a difference I think..
The description of the process model isn't that accurate. In both IE8 and Chrome the renderer process is shared across multiple tab groups. If you manually create a new tab that tab will have a new rendering process associated with it. If you click on a link and it opens in a new tab it will share the rendering process of the parent page. Chrome will show you this in the Task Manager as a single process which show a list of tabs.
The implementation of the rendering processes between IE8 and Chrome are strikingly similar, so much so that I am suspicious that Google borrowed some ideas from the public betas of IE8 which had this functionality since March. Both use the same behavior for sharing rendering processes as mentioned above. Both spawn the same image as the rendering process as the hosting browser process (iexplore.exe and chrome.exe), using command line arguments to pass channel information. Both use the Job API in Win32 to assign the rendering processes to security restricted jobs. Both use an IPC mechanism built on UDP messaging to localhost for the rendering processes to communicate back to the parent process, where plenty of other IPC options exist, and considering a lot of the Chrome code is Win32-specific they could have used platform-specific IPC for performance purposes without sullying the project.
Where Chrome differs is that unlike IE8 plugins are also loaded in isolated processes. It's a neat idea in theory but I think it will be problematic in practice. The browser shares one plugin process for all uses of that plugin, which I've already seen cause bottlenecks in resources on my machine trying to view several sites with Flash content. The plugin processes also have a lot of hard coded logic to deal with the nuances of the different plugins and how they behave. For example, there is hard coded logic to deal with the UI expectations of Flash where the content is rendered in the renderer process instead of in the plugin process, whereas with QuickTime the content is rendered in the plugin process and overlaid in the rendering process. In IE8 if a plugin crashes hard the tabs that contain the failing plugin would crash, but other pages would remain open potentially displaying other content using the same plugin. In Chrome if the plugin crashes hard it does so for every page displaying content with that plugin, although all of the tabs would remain loaded showing a placeholder where the content would be.
Konqueror has a windows port, too.
This is not entirely true. Normally the BIOS will remap IO address space above system RAM, but on 32 bit hardware (with or without PAE), the BIOS will generally reserve a hole somewhere between 3GB and 4GB. Depending on your specific hardware, this hole might be pretty big. For instance, if you have a 512MB video card, that memory gets mapped into the system address space, and you lose the same amount of system RAM for the privilege. There are some BIOS that will allow you to map this memory above 4GB but drivers sometimes flake out when you do that; plus you have to run a 64bit OS at that point too.
You will never see a 32 bit vista machine report more than 4GB of ram as it's simply not supported. (Makes you wonder why they turn on PAE by default since it slows down memory access?? A vendor turning PAE off is probably just smart.) You will, however, see vista report 4gb in the computer properties -- but it's more of a marketing trick. 32 bit windows will only allocate 2GB of address space to user processes anyway and 3GB only with a special boot switch (that you have to be careful with.)
As far as your claim that some cheap motherboards do not connect the PAE pins, that's also somewhat misleading too -- the pins are all there anyway -- its just the feature was left out of cheap junk northbridge chipsets... but this was back in the Pentium III days. It's very doubtful you can even find a board anymore that does not support PAE; especially since pretty much all current model CPU's have 64 bit support.
I think Chrome is actually doing exactly that.
e.g. Just open youtube and play any video. Now, Chrome Task manager shows three 'processes' - each with memory footprint and CPU usage - One for Browser, one for Tab, and one for Flash Plug-in. You can not kill the Browser process, but you can kill any other.
For more details, you can type "about:memory" in the URL and see what's going on in more details.
I only use 64-bit Linux these days. Since Flash isn't 64-bit yet, it runs in a separate process from my 64-bit browser, thanks to nspluginwrapper.
The only problem is, when it does crash, it doesn't restart until I restart my browser. So, my browser is fine, but I won't be watching any more YouTube. Better than a crash, but not as good as it could be. If anyone knows enough about nspluginwrapper to fix this, it would be awesome -- maybe even for 32-bit users.
I believe Chrome does this, too -- but I would hope that, since they've done it deliberately, as a way to minimize the damage a plugin can do, they would also be able to handle plugin crashes more gracefully than requiring a full browser restart.
Don't thank God, thank a doctor!
Link for the google-handicapped: http://windows.kde.org/ actually lists KDE 4.1 as a release for Windows. I'm surprised there wasn't more news about it though. It seems to still be alpha/true beta quality software though but interesting nevertheless. Nice for people like me who like KDE apps but also like Windows (gasp).
All your base are belong to Wii.
Mostly Wrong. The reason you don't see all 4 GB on Windows machines is a combination of 2 factors.
#1. Memory mapped devices. This includes device which has onboard RAM (video card is biggest factor with the 1GB of RAM that's usual now). This must be mapped somewhere in the physical address space (virtual address space is irrelevant for this issue). And for compatibility with 32-bit DMA purposes has to be below the 4GB mark. So modern motherboards will remap the "displaced" RAM above the 4GB mark so it is still accessible.
Now onto issue #2. Windows *could* use PAE to access this relocated RAM, but it doesn't on desktop editions (even if PAE is enabled). Technically from a hardware point, it should be accessible, but once again for compatibility purposes, the Microsoft folk have opted to simply not use any RAM seen above the 4GB mark. The reason why is because of poorly programmed 3rd party drivers which assume all RAM is below 4GB, and try to do 32-bit DMA (and thus trash random memory and crash the system). For Microsoft, it's easier to simply avoid the issue then explain why it's not there fault to customers. (BTW server editions are a different story and DO support using RAM above 4GB).
You can verify this by opening up Microsoft's "System Information" utility and going to the "Memory" section. Simply put, it does not show ANY memory above 0xffffffff despite the fact that I know for a fact that there is RAM mapped above that address (installing Linux with "64GB memory support", aka PAE support, shows this to also be true and DOES report and using all 4GB of my RAM).
This issue has NOTHING to do with "shared memory space between processes.
IE8 with 6 processes was using 958524 KB and Chrome with 11 processes was using 783840 KB.
Uhm, how are you counting that? There are 11 Chome.exe processes, and when you add their "Mem Usage" columns up you get 783840KB? Because, er, OS's which use paged memory VM's don't work like that; about the only way you can really work out how much memory they're all using is by comparing their VM mappings and seeing what bits are shared between them (and not also with other processes; e.g. standard Win32 dll's everyone uses) and which aren't.
This is why Chrome has about:memory, with an *estimate* of how much memory Chrome is using; if I spawn 11 tabs and add up Mem Use, I get 263MB. about:memory, however, estimates it's using 166MB, and a good chunk of that may well be in memory mapped files and as easily disposable as filesystem cache.
Konqueror uses Webkit, as of several months ago.
Correction: Konqueror can be compiled to use QtWebKit, but out of the box it still uses KJS/KHTML from the KDE Devs. If you don't believe me then check yourself on Debian or other distributions.
gz m8, do you work in the how-sensationalist-can-you-be! dept?
it's not an exploit. you cannot call it that because its a beta product. Beta products have bugs. its the same as a test driver saying a car is crap because feature is not correct. By downloading and using chrome, you submit to being a beta tester. if you're going to go around spreading negative publicity about a beta product that you are technically a tester of, in order to improve it, then you're a moron. call me a flametroll. just don't come post "0day sploits" about a beta product, because thats retarded.
are there to be used.
I'm old enough to remember this kind of argument about assembler vs. compiled languages. Hand coded assembler will always be smaller, and for any given algorithm it will very likely be faster. When viewed as assembler it will always be more elegant.
From time to time one comes across an assembly language application (although it's a lot rarer these days) that is a tour de force, doing the essential tasks of its compiled competitors in a fraction of the space and often noticeably more snappily. But they aren't notable for the breadth of features they offer.
And that's what bloat is about. Bloat isn't about using resources; it's about devoting resources to ideas that seemed like a good idea at the time but which you don't have the time or ability to undo. Sometimes the feature doesn't exist yet, or abandoned, but still leaves its mark. The reason that large assembler programs tend to be lean isn't so much that humans produce tighter code than compilers, although they can. It's because people who code in assembler think very, very had about any feature before adding it. You'd get much the same results if people coded in a language like Brainfuck.
Any application benefits from skepticism about features, whatever it is coded in.
Now, if you think about what Google is trying to do with Chrome, launching a separate process for each tab makes sense; it is a legitimate use of resources. Each tab is, presumably, hosting a different application. You don't want them running in the same address space, anymore than you want traditional applications running in unprotected memory by cooperative multitasking. Yes, it takes more resources to do this, but I've heard much the same complaint about virtual memory and process preemption.
You don't want some random site's malware to get to close to the online banking application running in a different tab, so you've got to take steps. If you're coding was perfect, those steps probably would work pretty well, but running the online apps in different processes is a legitimate use of resources. You can try to protect pages from each other, manage resources such as processor time between them, but eventually you're coming very close to making the browser an operating system in itself.
In fact, for the purposes of Chrome, the browser is an operating system, or at least a layer in the whole operating system that hosts applications. By taking advantage of the underlying operating system's facilities, the browser doesn't reinvent the wheel, but it comes at a cost.
There isn't a universally right or wrong answer to how to architect something like this. When considered as a hypertext viewer, this kind of architecture is wasteful and bloated. When considered as facility to participate in multiple distributed processing applications, this kind of architecture isn't bloated. It consumes more resources, but to achieve an important goal.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.