Chromium Blog: Multi-process Architecture
The day the Google Chrome comic was released quite a few people pinged and called me to talk about that and what I say about -- not that I am an expert on browsers or evaluating software products. Its just for the slight association with the Mozilla community that I was contacted. When I was talking with my roommate about this I told him what I felt the very moment I read about the multi-process architecture. Right from the first reading I was skeptical about the resource utilization if I were to open a hell lot of tabs in this browser, as it mentioned in the comic that each tab is a process. Though the phrase "process per tab" was more for software laymen with the actual thing being that it is "process per domain" until a max limit of about 20 and later its reuse. More details are on the blog post linked above.
And about the reason for being skeptical is the very basic concept amongst computer users that more processes will slow down the system. Any system analyst or a sys-admin will tell you the same thing when you complain about the very low speed of your computer. From what I know this is mainly because of the increased memory consumption and a possible paging that might happen for moving processes in and out of main memory and virtual memory. Also scheduling will possibly take a hit as there are more processes. Apart from this as I understand there is always an overhead of maintaining process info for every process.
Considering these things for a user like who opens close to 20 tabs always and goes up to 30 a lot of times, the overhead will be considerable. Also creating and killing processes will also be an overhead.
Also my task-manager will list so many chrome.exe processes.. !!!!! Thats so very irritating for me.
When I told him about my spkepticism he told me that the Google folks would have thought about that. I agreed with him and the now they have put it on their blog. In the post linked at the top, its mentioned that the system might slow down with a lot of processes and hence they had to put an upper limit and later resort for reuse. They call this small caveats but I am not sure if it is small enough. Lets see how things evolve.
Until this is proven as small enough: Happy Single-Process browsing ;-)
The day the Google Chrome comic was released quite a few people pinged and called me to talk about that and what I say about -- not that I am an expert on browsers or evaluating software products. Its just for the slight association with the Mozilla community that I was contacted. When I was talking with my roommate about this I told him what I felt the very moment I read about the multi-process architecture. Right from the first reading I was skeptical about the resource utilization if I were to open a hell lot of tabs in this browser, as it mentioned in the comic that each tab is a process. Though the phrase "process per tab" was more for software laymen with the actual thing being that it is "process per domain" until a max limit of about 20 and later its reuse. More details are on the blog post linked above.
And about the reason for being skeptical is the very basic concept amongst computer users that more processes will slow down the system. Any system analyst or a sys-admin will tell you the same thing when you complain about the very low speed of your computer. From what I know this is mainly because of the increased memory consumption and a possible paging that might happen for moving processes in and out of main memory and virtual memory. Also scheduling will possibly take a hit as there are more processes. Apart from this as I understand there is always an overhead of maintaining process info for every process.
Considering these things for a user like who opens close to 20 tabs always and goes up to 30 a lot of times, the overhead will be considerable. Also creating and killing processes will also be an overhead.
Also my task-manager will list so many chrome.exe processes.. !!!!! Thats so very irritating for me.
When I told him about my spkepticism he told me that the Google folks would have thought about that. I agreed with him and the now they have put it on their blog. In the post linked at the top, its mentioned that the system might slow down with a lot of processes and hence they had to put an upper limit and later resort for reuse. They call this small caveats but I am not sure if it is small enough. Lets see how things evolve.
Until this is proven as small enough: Happy Single-Process browsing ;-)
Do note that Mozilla has considered, and is considering to do something similar.
ReplyDeleteIt seems like IE also creates a new process under some conditions. [http://www.codinghorror.com/blog/archives/000966.html] I am not able to reproduce this, however.
ReplyDeleteThere are three costs to the multiprocess architecture:
1. Switching between page tables - this is relatively cheap.
2. Switching pages between disk and RAM. RAM is getting cheaper by the day, and as more and more people move to 64-bit, I guess this won't really be a bottleneck a few years into the future.
3. Interprocess communication: Even though all the tabs are rendered separately, it is quite conceivable that they need to share data. I'm curious to learn how cached data, history, saved passwords etc are handled in chrome. I don't expect any of these things to become performance bottlenecks, but they do put restrictions on how development proceeds on the browser.
My machine at home has very little RAM [256 MB], and it chokes with more than few tabs when using Chrome. I am waiting for the Linux version to see how the browser behaves on my laptop, which has 4GB and runs 64-bit.
I am not entirely convinced that performance is going to be bottleneck in [the lack of] Chrome adoption. Let's see what happens.
@Shawn:
ReplyDeleteInteresting to know that Mozilla is moving to this new model. I had talked to a couple of people on IRC about making out tabs multithreaded, but they were of the opinion that it would require a lot of work. I would like to see how this evolves.
Well, note that it hasn't been decided. It's being considered. See http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/06b9aade0a0ee360#
ReplyDelete@Pramod:
ReplyDeleteOf the three things mentioned 3rd is the most interesting. There are so many things going on in current day web pages or web apps as they are fondly called. Chrome as such does not sandbox each by itself, it works on the top level domain. Tabs with pages from same top level domain will be under the same process. This is probably to facilitate communication between the web apps.
And about chrome adoption, its not a significant thing in itself. I am more interested in their new model becoming successful and getting reflected in other browsers, if it is such a worthy thing.
As I said before until its proven that the caveats of this model are actually small, I will remain skeptical.
Thanks Shawn. I will follow that closely.
ReplyDeleteWe often come across a situation where you might have to close the entire browser when only one tab is hung. That is bound to happen when browser runs as single process [http://blog.chromium.org/2008/09/multi-process-architecture.html] Chrome is expected to behave better in this regard..
ReplyDeleteAlso, take into account that nowadays we have 1-2 GB RAM compared to 256MB some years ago. And, this forking can take advantages of multicore architecture.. which is the future!!
Also, if a tab is closed the memory related to that tab can be reclaimed!