Scalability
gregor-wagner.com
Scalability
1–10 of 165 posts
Re: Scalability
#2Really interesting. I wonder how these would have fared on Windows (Windows having a different threading system to pthreads)?
Re: Scalability
#3Interesting to see this being done on a more "normal" amount of tabs. That depends from user to user but IMO a ~50 tab for a power user.
Re: Scalability
#4It makes me a bit suspicious that a Canary build of Chrome is used. I understand that when a new feature is highlighted in a nightly build of Firefox, it's right to show it off - but why not do so against the latest version of Chrome - or even a Dev build? At least those two have been tested first ;)
Re: Scalability
#5Performance is the side-effect, not the cause. The cause is the fact that chrome uses separate processes both for security, and so if one tab crashes, you don't lose them all.
The fact that it uses more memory is a design tradeoff (although with shared text pages it's not as bad as one might think). The real question is whether you would ever have that many tabs open, and how much memory do you have on your desktop?
Re: Scalability
#6This has been what I've experienced for more than just the latest versions. In personal usage the crossover between Chrome and Firefox has always been in the neighborhood of 20-30 tabs. Past that. Chrome has always seemed more sluggish (and less usable, given how tiny the tabs get).
Re: Scalability
#7Performance is the side-effect, not the cause. The cause is the fact that chrome uses separate processes both for security, and so if one tab crashes, you don't lose them all. The fact that it uses more memory is a design tradeoff (although with shared text pages it's not as bad as one might think). The real question is whether you would ever have that many tabs open, and how much memory do you have on your desktop?
Firefox compartment memory as well. Using a separate process it the easy way, using thread is the hard way. Each has pro and cons I guess. Even Firefox is getting a multiprocess model for testing.
But for example you can't completely isolate a thread if it crashes. But you can forbid it to access other memory areas for security, that's what Firefox does.
Since Firefox 4 each tab has it's own separate garbage collector.
Re: Scalability
#8Thanks for posting test results. I am using Tree Style Tabs extension for FireFox and have _lots_ of tabs open all the time.
Now I don't need to test myself if I should switch to Chrome :-)
Re: Scalability
#9Performance is the side-effect, not the cause. The cause is the fact that chrome uses separate processes both for security, and so if one tab crashes, you don't lose them all. The fact that it uses more memory is a design tradeoff (although with shared text pages it's not as bad as one might think). The real question is whether you would ever have that many tabs open, and how much memory do you have on your desktop?
Firefox compartment memory as well. Using a separate process it the easy way, using thread is the hard way. Each has pro and cons I guess. Even Firefox is getting a multiprocess model for testing. But for example you can't completely isolate a thread if it crashes. But you can forbid it to access other memory areas for security, that's what Firefox does. Since Firefox 4 each tab has it's own separate garbage collecto…
>But you can forbid it to access other memory areas for security
Not in C/++ in any standard definition of "thread".
Re: Scalability
#10I know an anecdote isn't data, but here we go:
I often have >100 tabs open. I also sometimes have to restart my mac, and reopen those tabs. While Chrome then struggles for a few minutes, it doesn't take half an hour, like this article suggests, to open 100+ tabs.
And I did switch to Chrome from Firefox, as it seems to handle a lot of open tabs a lot better.