Hacker News Reader

Comment by taeric | Hacker News Reader

I think performance is often overblown on this as well. However, I don't think the overhead from task switching will really enter into it. If you have hundreds of tabs open that are trying to do work, that is work that was having to be done regardless. Meaning they would already be thrashing. Now, that will just be in a different way.

Otherwise, if you are idling most of those processes, they should be the same as before. Just idle.

Memory, on the other hand, I think will go up. Not sure by how much, though. I would think the rendered content would be the largest consumer of memory. And again, if you have hundreds of tabs open with high memory usage per tab, that should already be a problem. Right?

View on HN

Firefox: Averages ~5MB/tab (200 tabs, 1GB memory)

Chrome: Anywhere from 50MB/tab up.

A much better performance fix would be to suspend javascript execution on tabs that aren't visible.

I am not questioning reasons to have 200 open tabs, but wonder how do you manage it? I would imagine tab bar become very long?

It helps that Firefox offers to change to an existing tab when you try to open the same page in a new tab.

Another suggestion is to not manage it. I create tabs all the time, and often have many similar tabs. There's no need to manage it, only to clean up once in a while.

(I like many tabs. A few weeks ago I performed some tab-cleaning -- 550 tabs were a bit much, as it made Firefox start slower.)

Personally i just use it for things I would like to read at some point, instead of filling up my bookmarks with 50-10 entries every day.

>It helps that Firefox offers to change to an existing tab when you try to open the same page in a new tab.

Disabled that as soon as it was dumped on me. There are an almost infinite list of reasons to have multiple copies of tabs.

Honestly, I cleanup every week or two, and it works fine. Windows are by category of different things I do, and I tend to leave frequent sites open all the time.

I wish it had an option to reorder that tab (move it to end / bottom in TreeStyleTabs). (also, reverse order of tabs in TreeStyleTabs would be great).

The TabPolish Chrome extension implements similar behavior (in a slightly different way; it doesn't hook into the suggestion menu, and duplicate detection is per window, rather than per browser instance).

I find it essential to manage the mess that is my Chrome tabs.

The Tree Style Tab extension [1] makes a world of difference here. My tab bar basically becomes a stack of ephemeral bookmarks.

[1]: https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...

With high-res, widescreen monitors, it makes a lot more sense to have tabs in a vertical stack. Check out Tree Style Tabs for Firefox: https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...

This is the must-have feature that keeps me using Firefox -- especially when I'm doing research, which has a naturally tree-like pattern. Apparently, from the Chromium bug, it's a dealbreaker for lots of other people as well: https://code.google.com/p/chromium/issues/detail?id=344870

I deal by creating multiple windows, ideally one per general topic/use case. This works great with Chromium because you can easily drag multiple tabs between windows to organize things, and the shrinking tab bar encourages you to close things you don't need. Doesn't work so well in Firefox, where you have to manually drag each tab over one by one, doing so is kinda glitchy, and the scrolling tab bar makes it easier to just fill a window with a ton of unrelated tabs.

There's an addon for that: https://addons.mozilla.org/en-US/firefox/addon/multiple-tab-...

Although I don't get anywhere near 200 tabs, I hit the same type of UI management issue. I use contextualized "sessions" using panorama in Firefox (Ctrl-Shift-E). I have 10-20 tabs per context, and somewhere between 6 and 10 contexts. Between Panorama and TreeStyle tabs (a plugin), everything is neatly organized.

Panorama is a life-saver if you have to context-switch between projects regularly.

TreeStyle, really, I use more as a means to move screen real-estate to horizontal usage on my laptop's 16:9 screen. Tab organization is a side benefit.

Right, this is just memory, though. And I am curious on whether or not this counts shared memory correctly between tabs.

My point for performance, though, was mainly that if you have 200+ tabs that are actively doing something, then you are thrashing even in firefox. It isn't like they just do their work for free depending on the process model.

Also, 200 is not exactly a large N when we are too worried about scheduling, is it? (That is, unless all 200 are cpu bound, in which case, again, firefox would already be thrashing.)

On Chrome, the OS can page all those other tabs to disk without affecting performance of the current tab. On Firefox, you're going to feel it.

Why can't the OS page Firefox's memory to disk too? Paging is done at much finer granularity than per-process.

Because, as I said earlier, "you're going to feel it." If your tabs are allocating in the same process address space as each other, accessing your current tab's data is likely to cause swapping. The key point is that electrolysis and chromium-based browsers can page inactive tabs "without affecting performance of the current tab."

This isn't really intuitive, though. When you switch to a tab, either you page in that tab's memory for the current process. Or you page in that tab's process and memory.

That is, by going to a "per process" approach, the amount of memory that gets paged in almost certainly went up. No?

The amount of memory that gets paged in went up, but the whole point is that you never have to page any of the current tab's memory while you're using it, unlike with the monolithic 1 GB Firefox process today.

I feel like I must not have been clear earlier because I have made just a single point, and both of you are discussing things not related to that point. Let me try one more time: it's all about performance of the current tab.

Right, and the counter point is that this should not help there. If the other tabs are idle, than they are idle whether in process or not. If they are all cpu bound doing stuff, then your machine is again in trouble, current process or not. If they are all constantly thrashing in resources, you are still in trouble.

Why would you think the current monolithic would page out a tab that was actively being used? Why would this not also happen in the "per process" approach?

That is, how would this specifically help? If you are actively using the memory for the current tab, because it is the current tab, why would it be swapped out under the monolithic case where it would not in the per process case?

I'm perfectly willing to accept there is a scenario I am not considering. I just don't see it, right off.

Because the tab you're using has barfed its data all over the heap, so you can't keep all its data paged into main memory. Its data is mixed together with the other tabs' data.

At face value, I don't see why this should necessarily be the case. That is, why would a tab "barf its data all over the heap?" More directly, why couldn't, as the sibling said, this have been addressed with a different allocation mechanism.

I'm assuming this has come up a fair bit. Any good links to read up on this?

I still don't see the scenario you're describing, though. Let's say you have two tabs open, A and B. Then some set of pages will have memory for A, and some set will have memory for B. If you're not using A, then the operating system will notice that those pages have not been used in a while and if under memory pressure it will page them out. This won't affect pages with memory for B.

The only issue would be if most of the memory allocations are under your system's page size (typically 4096 bytes) and distributed randomly, so that a lot of pages have data structures associated with multiple different tabs. But I think that's unlikely, and even if it is true, couldn't it be resolved by making your allocation strategy tab-aware (e.g., by giving each tab its own malloc arena, which would be way simpler than splitting the browser into multiple processes).

Am I missing something here?

You get it. The one thing you're missing is that application-aware allocation is hard and something that Firefox engineers continuously have to work on (http://blog.pavlov.net/2007/11/10/memory-fragmentation/), even as they add new features and performance caches. The electrolysis/chromium solution makes the problem disappear entirely (along with some security problems) without any possibility of regression.

Hmmm, I have 10 tabs now and Mac's "Activity Monitor" shows FF is using 571MB of RAM.

Not sure about the ~5MB/tab figure.... This is FF 32.0.

Talking about "memory usage per tab" doesn't make much sense unless you talk about what's in the tabs. It's rather like talking about "memory usage per application" on your desktop and not mentioning whether the application is ed or OpenOffice.

Suspending JS execution in invisible tabs seems highly unlikely to be web-compatible; you wouldn't want YouTube or Spotify to stop playing just because you focused a different tab. On the other hand, with technologies like requestAnimationFrame, we can make it possible for well designed applications to work well when in the background.

Reply on news.ycombinator.com