Confirmed users
2,492
edits
Electrolysis/Firefox: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 24: | Line 24: | ||
* Security improvements are a non-goal for e10s. We do believe that this project will net some security gains but it's not an explicit goal. In general the app should be no less secure than Firefox 4 but there is no additional security bar. | * Security improvements are a non-goal for e10s. We do believe that this project will net some security gains but it's not an explicit goal. In general the app should be no less secure than Firefox 4 but there is no additional security bar. | ||
* There are | * There are 2 areas that are not really addressed by e10s but could possibly be effected. They might improve or they might degrade when we turn on e10s. A a minimum, we would want the following measurements to be equal to the Firefox 4 performance. | ||
** Page load time | ** Page load time | ||
** Startup time | ** Startup time | ||
| Line 31: | Line 30: | ||
==Targets== | ==Targets== | ||
There has to be a way to quantify our e10s goals not only to know we have been successful but also to know when we are done. This involves understanding what metrics and targets will be measured to enable us to determine we have been successful in achieving the goals outlined above. | |||
<insert targets here> | <insert targets here> | ||
| Line 40: | Line 39: | ||
<areas where perf can't degrade> | <areas where perf can't degrade> | ||
==Risks== | |||
There are a number of problem or risk areas we have identified that will have to be tackled early on in the project. Some we understand how to mitigate, others we are not sure. | |||
*1. What are all the places that chrome touches content? | |||
** We really don't have our head wrapped around this. | |||
** We can instrument the code to tease out some of this information and the patterns. | |||
** We need to engage people familiar with this code to participate in early discussions and help tease out the highly interactive areas. | |||
*2. Extension Capability | |||
** We need a migration path and plan for this. | |||
** We need some developer outreach to help us figure out the right strategy. | |||
** We need developer friendly solutions. | |||
** Good documentation, guides to porting. | |||
** Add-on team should be involved in this. | |||
*3. Risk of performance impact | |||
** We can help this by having clear benchmarks early with tools in place to measure them. | |||
** We can be measuring regressions very early on. | |||
** Architecturally we need to be thinking about solutions that will minimize the need to go between the parent/child processes. | |||
** Responsiveness is clearly the priority and architecturally things don't have to be as pretty and refined. | |||
*4. Goals, metrics and measurements | |||
** We need clear goals, metrics and measurements at the beginning of the project. | |||
** It's clear what we are aiming for and going to measure. | |||
*5. What scale of architectural change is required in certain areas? | |||
** Figure out early on what areas are easy to change and what areas are going to have to be rewritten completely. | |||
** There should be correlation between this and identifying the things that cross content-chrome boundaries. | |||
*6. Existing test coverage | |||
** Are there things we were not testing before that we should be now. | |||
** Find the areas that don't have test coverage. | |||
*7. | |||
==Implementation== | ==Implementation== | ||