Linked by Howard Fosdick on Fri 2nd Dec 2011 10:16 UTC
Permalink for comment 498743
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
More Features »
Sponsored Links



Member since:
2007-06-22
http://lawrencemandel.com/2011/11/15/update-on-multi-process-firefo...
Apparently it's too hard ... :rolleyes:
There is a misconception here: Having content in its own process(es) is not a silver bullet against interface lag. In fact, independent of where content lives a lot of stuff will have to be done in the single browser process (e.g history access, I/O, etc.). That's where Firefox has some glaring issues currently like doing a lot of synchronous disk I/O stuff which leads to noticeable lag or badly performing SQL queries to their Places database (where history, bookmarks and favicons live).
This work would have to be done anyway independently of Electrolysis to improve the user experience and Mozilla thinks they will get better short and mid term results by pooling their resources into these areas. We'll have to see how this plays out but the issues they are trying to solve are orthogonal to Electrolysis and not a replacement.
Electrolysis helps with other things: Content-induced load, security and better resources tracking (although Firefox does already a good job via about:memory).
You can also bring down Chrome easily to its knees, for instance, when restoring large sessions (>20 tabs). At least for me the interface becomes very unresponsive until all tabs are loaded.