Live data from Hacker News

Scalability

gregor-wagner.com

11–20 of 165 posts

Re: Scalability

#11
post #6

This 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).

Likewise. I typically keep open a large number of tabs, opening a pile of links at once and then going through them during the working day. At any one time, I tend to have a hundred-odd tabs open.

Although to be fair, firefox isn't too happy with that workflow, either - but I blame that partially on flash and javascript.

Re: Scalability

#12
This has been the main reason why I have not totally committed to Chrome. While I do not usually have 100 tabs open there are times when I do have 30 - 40 open. In Firefox the browser slows down but not horribly so. In Chrome the browser is still usable but it is noticeably slower than Firefox.

I love everything else about Chrome and while I realize that the degraded tab performance is a trade off, it still bugs me enough to not do a full and complete switch. That is why when I am casually browsing the web I will use Firefox. But when I am using a web app or working, I will use Chrome.

Re: Scalability

#13
My Chrome default startup settings open about 40 tabs. Sometimes in addition to this I might open 20 or more news articles in rapid succession in order to scan headlines and lead paragraphs. I've noticed this effect many times.

Still, I can't help but think this is a tweak. I mean, at the end of the day, we're talking about CPU time, memory allocation, and processing priority, right? So allocate a few extra processes and large chunks of memory, set the priority such that Chromium doesn't tank the system, then work a buffer allocation system.

Of course, that's rampant speculation on my part. Seems like I read somewhere that timing and process priority is still an unsettled issue in Linux, so I know it's a lot more complicated than I make it out to be. (But I also know that having 150 processes do things without hosing things up is by no means an unusual situation in any operating system.)

Re: Scalability

#14
I recently switched from Firefox to Chrome after their appalling release of Firefox 4 & 5. 5 Is better than 4, but only slightly. In most cases, Chrome out performs Firefox now and it's a shame that I had to switch from Firefox.

Although these are real world statistics you encountered, I still think that Firefox needs to buck their ideas up and start releasing more stable versions.

Re: Scalability

#15
post #9
post #7

Earlier quoted context omitted.

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".

What you mean is not in a mandatory fashion and at the C code level and that's true. But what I meant is that you can do it for the objects you manage, such as JS code and the rest of the webpage. It doesn't prevent an issue in the Firefox interpreter itself.

Re: Scalability

#16

I recently switched from Firefox to Chrome after their appalling release of Firefox 4 & 5. 5 Is better than 4, but only slightly. In most cases, Chrome out performs Firefox now and it's a shame that I had to switch from Firefox. Although these are real world statistics you encountered, I still think that Firefox needs to buck their ideas up and start releasing more stable versions.

The version in the story is Firefox nightly aka Firefox 8. There are many changes from Firefox 5 to 8. Since they adopted the rapid release, Firefox 8 won't take forever to be stable, but it will still take a few month.

Re: Scalability

#17
post #10

I 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.

I'm pretty sure the total time depends on which webpages you open.

Also please note that this is for Firefox nightly (8) only. This might also be true for FF 6 and 7 but nothing before that. Memshrink enhancements have only started at FF 6 (which is not yet released as stable, but soon)

Re: Scalability

#18
Opera's doing just fine. As I am writing this, Opera has all 150 tabs open and still feels snappy. ~1.5GB memory and ~30% CPU (currently). I could not measure the time but it was well below 10min.

Re: Scalability

#19
post #5

Performance 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?

The limit is found pretty soon on older machines; while the OP tests on a Mac with 8GB of Ram, on my main machine I have only 2GB of Ram, and Chrome becomes unresponsive after ~10 tabs opened.

I didn't think Firefox would be better but if it is, I might go back to it!

Post reply on HN