Why? Except because of memory allocation serialization impact, there is no reason for a multithreaded process being slower than multiprocess. And if that's the cause, it could be solved using multiple heaps.
My guess is that the multithreaded-only design wasn't as good at exploiting the inherent per-tab parallelism. The original architecture probably had some synchronization points (perhaps related to the common GUI code) that did not allow processing each tab truly independently. Regarding memory allocation, yes, in theory one should be able to try to avoid sharing data across threads, which should eliminate serialization on memory allocation and deallocation. But I can easily imagine that in practice, in a codebase that was not explicitly designed to process each tab in parallel, you'll still end up sometimes sharing data across threads.
I imagine they could have instead changed the architecture to be multithreaded in such a way to avoid my imagined sequential bottlenecks, but performance is not the only goal in a multprocess architecture. Sandboxing is another design goal, and that cannot be fully achieved with a multithreaded design.
This is all speculation on my part, so if anyone who actually works on the Firefox codebase could correct me, that would be very welcomed.
The current setup is not multithreaded in the relevant ways.
So the real decision point was whether to take an existing large C++ codebase and try to safely make it multithreaded or to take that same existing codebase, run it in separate processes, and make the communication work.
The latter is actually a simpler engineering task, in my opinion, and paves the way for doing things like sandboxing and whatnot once the initial rollout is complete.
One near-future goal is to move the compositor out from the UI process into its own separate one. Mozilla currently maintains a sizeable blacklist of {feature, GPU, OS, driver} for hardware acceleration because glitchy drivers cause whole-process crashes. When this occurs a separate compositor process can be restarted instantly without the user noticing.
I'd guess that it wasn't the effect of switching from threads to processes that made the difference. It might come from code clean up and fixing some of the IPC that was going on. This would have probably seen many eyes in the firefox dev community so they might have made some efforts to clean up the code under the hood before closing the lid on it.
But I might be wrong as I have no ties to the development process of this.
