Re:Ubuntu: “How are we improving Firefox snap performance?”
by yjftsjthsd-h on Saturday September 03, 2022 @01:27PM
(#32704074)
Does Chrome, which has been made of many processes since day one, have the same problem?
Re:Ubuntu: “How are we improving Firefox snap performance?”
by mort96 on Saturday September 03, 2022 @01:50PM
(#32704283)
This comment (https://news.ycombinator.com/item?id=32702062#32703005) from this thread links to this post: https://neugierig.org/software/chromium/notes/2011/08/zygote...
TL;DR: right after launch, Chrome forks off a helper process which is then responsible for forking off child processes, so that all child processes use the same process image as the main Chrome process. It also opens all files it will need right after launch and just re-uses the same file descriptors, so it always keeps references to the old files. This is complicated and brittle and a source of bugs, but when everything works and nobody makes a mistake, it means the old Chrome can keep running without problems even after all its files have been replaced with those from a new Chrome.
At least that's how it worked in 2011 according to Evan Martin.
The reason it no longer works is that tabs run in separate processes. This means that if a tab causes the engine to crash, only that crash (or a small number of tabs) crashes, while Firefox itself and all other tabs keep working, and if there's a sandboxing bug, you still have process isolation which prevents one tab from spying on another. But it also means that if you replace the binary without restarting Firefox, the parent process and the content process will be different versions and they can't really talk to each other.
Software engineering is all about trade-offs. We get improved performance, improved security and improved reliability, and we pay with increased memory usage and a less smooth upgrade process. Personally, I'd say that's a clear improvement.