Submitted by Chrome’s process model is extremely sophisticated. The default behavior has been examined before, but you can configure Chrome to manage processes differently: one process per web site, or one process per group of connected tabs, or one process for everything. Marc explains how this all works in Google’s new browser. Update: ‘Read more’ fixed – made a reading comprehension boo-boo there.
Basically, you can run Chrome in four different modes, which are more or less self-explanatory when you look at the command line arguments passed to the executable.
--process-per-site-instance<br />
--process-per-site<br />
--process-per-tab<br />
--single-process<br />The first one is Chrome’s default, and is quite tricky to explain, so I’ll just let Marc do that for us.
Completely separate visits to the same site are managed by different processes, so if you had two tabs open to mail.google.com, one of them could crash without affecting the other. Chrome treats separate browsing contexts as separate processes.If you’re on mail.google.com, and you navigate to hotmail.com, the tab’s underlying process may switch. In this case, Chrome switches your browsing context because you navigated to another site.
If a web page pops up another webpage (via Javascript), then the sites are considered connected, and managed by the same process. Chrome uses a single Renderer process to handle a browsing context.
Process-per-site means that for instance mail.google.com, docs.google.com, and reader.google.com all run in one process. Process-per-tab says it all, really; launching Chrome with this argument means each tab gets its own process. Finally, the single-process argument turns Chrome more or less into a normal browser, where there is only one process running.
The great thing about this is that it allows you to fine-tune Chrome’s way of handling system resources in such a way that it suits your hardware and/or browsing habits best. It would be interesting to see any benchmarks performed with the various arguments, to see if they make a noticeable impact on performance.
Your Read More summary is wrong. According to TFA the default is “–process-per-site-instance”. What you describe is the optional “–process-per-site mode”.
Who gives a rats ass?
Google isn’t really doing anybody a favor with this browser.
If you look really closely you will see that it is still a beta, but they do _not_ tell you that it has lots of unpatched security flaws and that running a beta has serious implications.
There are active exploits for Chrome and the security and privacy are just horrible. (http://security.bkis.vn/) From the way it is build, installed and preconfigured it just sucks, but people think Google betas are just like other peoples final releases. Gmail is beta for how long now??
Conclusion:
Avoid Chrome.
I’ve been watching the Chrome ‘vulnerabilities’ very intensely. Besides this, there have been ~5 others, all just crashes (“denial of service”). If you’ll remember, Safari didn’t have too great a launch on Windows, either.
… but when this is production code, giving the general public this knob that can be set four ways is just shifting work from the developers to the users.
There are also going to be more bugs; the four different modes of operation are going to tweak different bugs. And if a design goal is that one tab can die without hurting the others, and you put out a comic book bragging about this, why not just implement it that way and be done with it?
Sure, if you go along with the one user fits all approach, then yes, the developers should sit down ‘the user’ and test him till he bleeds to find out which method is best.
Being rather subtler than that, however, they have tested, and provided, an optimal default that 99% of users are expected to be satisfied with. People with non-standard hardware or software requirements however, can, with a little research, find out how to make chrome suit their particular needs more often.
This sort of customisability is applauded in most Open Source software, why not this piece?
I voted you up because I think you bring up a good point, but I disagree. It could cut either way. I agree with you that more defects in the code will be manifest by giving users more flexibility with how they use the program, but the argument could also be made that forcing the developers to accommodate a larger variety of usage scenarios would force the overall code quality to be higher to reach release quality.
From reading their development website, one of the reasons they went with the option of operating in the single-process model was because it’s easier to debug using the standard Visual Studio debugging environment. Once they had the feature, what’s the point of suffering the pain of removing it, especially since they expect some of the users to also work on developing Chrome’s open source codebase?
[Posted from Chrome, on which I just seem to have hit a scrolling bug]
A set of command switches isn’t an explanation.
People who can call Chrome on the command line to find those out would understand what they did.
Still, nifty that it’s that flexible.
http://dev.chromium.org/developers/design-documents/process-models
Now that’s more like it! Why wasn’t this the article!