investigate utilizing multi-process (e10s/fission) support for calendar
Categories
(Calendar :: General, enhancement)
Tracking
(Not tracked)
People
(Reporter: mkmelin, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: perf, Whiteboard: [fission:thunderbird])
Bug 1646648 laid some ground work for Fission.
This bug is to make use of that support for calendar.
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
||
Comment 1•3 years ago
|
||
Please add key word "PERF".
|
||
Comment 2•3 years ago
|
||
I think that when looking at this bug, the architectural issues mentioned in bug 1658026 comment 9 should also be looked at. Otherwise we are "paving over" the startup architectural issues that I think calendar has by moving them to a separate process.
|
|
||
Updated•3 years ago
|
|
|
||
Comment 3•2 years ago
|
||
Sean, was this what you were recently referring to in matrix?
|
||
Comment 4•2 years ago
|
||
I'm not clear on exactly what Magnus intends this bug to cover. One of the goals of the provider rework is to move event sync and processing out of the main thread, but I'm not sure if there's something more/different intended here.
|
Reporter | |
Comment 5•2 years ago
|
||
With fission every tab (or is it even every frame) has their own process (own main thread), so if a site is slow or crashes, it's mainly a problem for that site, not the application itself. The intention in this bug is to figure out if we can achieve similar separation for the calendar: the calendar would be one "site", that does everything calendar. It would have to communicate with the "mail" site and others.
Description
•