There are number of things we believe the e10s project will give us:
...
2. Improved performance, especially on multi-core machines.
3. Better memory core stats."
That seems to directly contradict your concerns. However, these are stated goals and may not align with practical reality. I'd be surprised if, when these are numbers 2 and 3 on their list of priorities, the reality would be so very different.
Those 3 months can make a world of difference. I'd like to see it in action before I decide whether it is a good or a bad thing.
Also, I'd be very surprised if the numbers in this little test are more than anecdotal. Performance will depend heavily on the kind of content you're viewing and I'd wager that the IPC calls make up a very small minority of the runtime profile for a tab process. Also, not everything is so performance-critical. For instance, if response to a mouse click went from 1 to 7 milliseconds, would anybody notice it? If everything in the browser just slowed down by a factor of 2, would Mozilla really ship it?
> if response to a mouse click went from 1 to 7 milliseconds, would anybody notice it?
Considering that a frame at 60fps is ~16.7ms, YES. That's 42% of your total frame budget!
And it's not just IPC calls, either. There are many things that are less efficient when you segment things between multiple processes.
Also, you're completely ignoring / missing the point of memory use. FF (or rather, Pale Moon) is currently using >1/4 of the RAM on my laptop. And swap is (really really really really really) slow.
The exaggerated response time example was for a typical usecase. The amount of situations where there is actually 60fps rendering going on and necessary are few and far between. Most browser usage is of fairly static content. Especially in the case of a mouse click, when you expect something to change on the screen and almost everything in that change will depend on something much slower than the simple IPC call (if that even happens) of tranferring the mouse click event. Splitting things up between multiple processes can slow things down if done badly, and can also bring tremendous speedups if done right. I assume the folks at Mozilla know what they're doing.
And yes, I'm ignoring memory usage for now. Mostly because it is a horribly complex thing, especially in multi-process situations. The numbers are notoriously difficult to interpret between working set, commit charge, shared memory, memory mapped file IO. Unless you're actually debugging the code or an expert, it's basically just guesswork. Mozilla have improved Firefox's general memory footprint significantly these past few years and they're not going to throw those advancements away easily. Again, I trust them to know what they're doing.
As I said before, I'll reserve judgement on e10s until I get to experience it in daily use. All I will say in advance is that the premise and the stated goals make a lot of sense to me and it seems like a highly desirable technology.
There are advantages, but it is not without its disadvantages.