Black Raven Dragoons

[Zancarius]

Sort of old news (it came out yesterday), but if you haven't upgraded you might want to. There's quite a few changes and updates in this version.

Some of the interesting changes involve purported speed increases. I usually have more than 160 tabs open, so I can't really say for certain it's all that much faster.

[Snobal]

I'd like to see you open 100 tabs in IE8... seeing how every time you open a new time, it launches a new instance of itself >.>

[Zancarius]

Since IE 8 switched to processes (I think), I'd imagine it'd have a considerably higher overhead--if it worked. Although, Chrome suffers from the same shortcoming.

[Snobal]

This is from the latest available install.

[Zancarius]

Is that from task manager? 'Cause most of the memory it reports is very likely shared between processes. (It doesn't discriminate between shared memory and instead reports the individual process memory as process mem + shared.)

In any event, being as it's MS, I'm sure there's still some waste.

[Damorte]

Since IE 8 switched to processes (I think), I'd imagine it'd have a considerably higher overhead--if it worked. Although, Chrome suffers from the same shortcoming.

I tried Chrome, hated it. I don't even know why, maybe I'm just spoiled with Firefox and all its beautiful glory.

[Zancarius]

Chrome is over-simplified in my opinion. Google does a really good job at UI design, but there's a point when excessive minimalism is detrimental to usability.

I use it as an alternative browser to keep other documentation open when I don't want to flip through tabs in Firefox. However, Opera does just as well (actually better--Opera's interface is much nicer than either Chrome or Firefox). Chrome also has issues with paging if you have about 10-20 tabs open and haven't used the browser in about 2 hours. It becomes sluggish and can take up to 2 minutes to close from a commanded close event. It's based on KHTML/WebKit just like Safari but the real problem is in the design. (Both in terms of program structure and aesthetics. The design of Chrome feels too cartoony in Windows XP. It looks a lot nicer in Vista/Win 7 with aero but the interface still feels odd.)

Now, in terms of why Chrome does have some deficiencies in Windows, it's important to understand the limits of the OS. In most environments (Erlang, Stackless Python, and other concurrent programming environments notwithstanding), there are two primary ways to provide concurrency in an application: Threads and processes. Processes are largely individual programs (like Firefox, AIM, World of Warcraft, and so forth) that are isolated from each other. Threads exist within a single process and interact with each other to provide a form of concurrency. Firefox, Opera, IE 7, and a few other browsers utilize threads internally to provide for UI responsiveness (when you click stuff) while loading things over the network (network threads) and handling tabs. Chrome and now IE 8 launch each tab in a separate process. There are advantages and disadvantages to each approach:

Advantages of threads:

1. Simpler than processes.
2. Lower overhead (consume less memory)
3. Easier to communicate data between threads and the main thread (application)
4. Threads are MUCH more efficient to use under Windows than processes--more on this later.

Disadvantages of threds:

1. Higher overhead than greenlets and coroutines which don't require the C stack frame to exist (hence why they call it Stackless Python). This means that threads actually consume a significant amount of memory just from existing because the system has to allocate resources "just in case" the thread might use them. The exact amount of RAM allocated depends on the OS and architecture. 64-bit platforms require larger frames.
2. A single dying thread can potentially cause the entire application to freeze and crash.
3. Concurrency issues can be a pain. If you're manipulating the same data set in a thread, you can run into issues that are only resolved by complicated locking, semaphores, or other techniques to ensure that only one thread can manipulate a specific value at any given time.
4. Not all operating systems provide threads. (This is changing.)

Google and Microsoft are switching to processes because of point #2. I'll explain why after covering processes.

Advantages of processes:

1. Each process is isolated from other processes. If one process crashes, it typically won't hurt the application that launched it. Instead, the host application simple restarts the process that died.
2. Fairly portable. Nearly all operating systems support processes except for old, antiquated, and certain embedded systems.
3. Resource locking techniques aren't as critical. They're still needed, obviously, but because processes are isolated from each other, the communication techniques needed for processes to talk with each other limit this particular problem by virtue of design.

Disadvantages of processes:

1. Much higher overhead and resource consumption than threads, typically on the order of 3-4 times (depending on OS). Under Windows, processes are far more costly to start than under Unix/Linux OSes.
2. Interprocess communication is a much more complicated issue than interthread communication. Worse, it largely depends on platform. Unix domain sockets are a great way to allow multi-directional communication in Unix and Unix-like systems. These don't work under Windows. Shared memory, pipes, named pipes, network sockets... the list goes on. There are some standardized libraries available for IPC, but availability depends, again, on platform. If you design a process-based application for Windows, porting it to another OS can be difficult depending on what is chosen to resolve this issue.
3. Some OSes have a much more strictly limited number of processes that may be run per user than threads. If all applications were process-based, exhausting the allowable process allocation per user would very likely become commonplace. Obviously, as hardware improves this shouldn't be an issue--but if you have a real mean SOB of an administrator (BOFH), good luck getting anything done.

Obviously this isn't an exhaustive list, but these are just some of the things I could think about in a reasonably short time frame without doing some research.

Anyway, as promised. The commonly-stated reason Google has for choosing processes over threads ties to stability, particularly Flash. If an extension, like Flash, dies in Firefox, it'll upset the current thread rendering the page and potentially trash the entire browser's state. If the browser doesn't die, a forced-restart is almost certain. Contrast this with Chrome: if Flash brings down a single tab (running as a process, remember?), you simply need to restart the tab and open the site back up.

I'm not so sure the extra overhead is really worthwhile. Frankly, I haven't had much trouble with Firefox's stability as of 3.x. I know a few folks have some issues with random crashes, but outside of profile corruption and the likes I've never seen an inexplicable crash that wasn't necessarily OS-related.

Random crap that came to mind during this article includes things like the language benchmark. It's a great read, and it's surprising to find that Java performs about as well a C in some environments (and it's naturally threaded). GUI code in Java still sucks.

Though, for highly concurrent applications it looks as if Erlang is the way to go. It powers telecommunication software, which is probably about as concurrent as you can go (thousands of simultaneous calls and so forth). Can't really do that with threads or processes.

Geek off.

[Damorte]

Chrome is

Then my ADD kicked in....

[Zancarius]

ahahahah

TL;DR: Chrome is slow. Use Firefox.

(The other crap is there for people who might want to know why. Don't read it if you don't. Trust me.)