Firefox OS/Performance/Boot Sequence Optimization: Difference between revisions

Jump to navigation Jump to search
m
Line 105: Line 105:
**  ~16s = Vertical
**  ~16s = Vertical
**  ~25s = UI presented to user
**  ~25s = UI presented to user
Of note is that there exists a pronounced black screen between the T2mobile and the "Mozilla Developer Network" logos, that was introduced at some point. Dave Huseby has noted in the past that such a noticeable black screen exists in other devices. This was less visible in past versions.


Of course, more concrete data will be explored later, but that is the general gist of things.
Of course, more concrete data will be explored later, but that is the general gist of things.
Line 112: Line 114:
[http://people.mozilla.org/~jbailey/v121-2-premainb2g/ Experiment #1]
[http://people.mozilla.org/~jbailey/v121-2-premainb2g/ Experiment #1]


In this simple experiment a simple change to "init.rc" was made. By default b2g was started along with a host of other services in the same class "main". For this experiment B2G was moved into its own class that was run just before main. As expected this did not have significant effect in when B2G was launched however, since these were all launched in fairly quick order. Quantitatively one does notice a difference in the bootchart images reflecting B2G being started slightly earlier. Of note is that as a result of this change, there is a more pronounced black screen between the T2mobile and the "Mozilla Developer Network" logos. Dave Huseby has noted in the past that such a noticeable black screen exists in other devices.
In this simple experiment a change to "init.rc" was made. By default b2g was started along with a host of other services in the same class "main". For this experiment B2G was moved into its own class that was started just before main. As expected this did not have significant effect in when B2G was launched however, since these were all launched in fairly quick order. Quantitatively one does notice a difference in the bootchart images reflecting B2G being started slightly earlier.  


[[File:baseline-bootchart.16.png|800px|Baseline, B2G is launched along with other services]]
[[File:baseline-bootchart.16.png|800px|Baseline, B2G is launched along with other services]]
[[File:premainb2g-bootchart.16.png|800px|Launch B2G just prior to other services in main]]
[[File:premainb2g-bootchart.16.png|800px|Launch B2G just prior to other services in main]]


In these images, each horizontal bar represents the lifetime of a process. A processes children are below it, and parent child relationships are indicated by a dotted line from the parent going into the beginning of the child's bar. The process bars are in order of launch time (earliest first).
In these images, each horizontal bar represents the lifetime of a process. A processes children are below it, and parent child relationships are indicated by a dotted line from the parent going into the beginning of the child's bar. The process bars are in order of launch time (earliest first). Blue segments of the bar represent CPU activity while pink segments indicate IO.


Based on the current code, the earliest it is conceivably possible to run B2G would be in the early-init stage of init.rc. This stage was observed to be executing at around 4.8s of uptime. Realistically a lot of things would need to be changed for this to work (that is to say, a lot of things break when this is attempted). A more logical stage would be early-boot (which is not used in the default init script, however is a supported stage that occurs between post-fs-data and boot). What is notable about this stage is that, A.) if done here, B2G launches at around 5.8s and B.) It successfully runs. Sometimes. There are clearly some dependencies that are not quite guaranteed to be ready if one attempts to launch B2G this early, which could be the subject of a future investigation to see if those dependencies could be moved earlier as well. However as it stands, this only launches B2G around 2 seconds earlier. and there actually was no decrease in overall boot time observed (again dependencies not being respected comes to mind as an explanation).  
Based on the current code, the earliest it is conceivably possible to run B2G would be in the early-init stage of init.rc. This stage was observed to be executing at around 4.8s of uptime. Realistically a lot of things would need to be changed for this to work (that is to say, a lot of things break when this is attempted). A more logical stage would be early-boot (which is not used in the default init script, however is a supported stage that occurs between post-fs-data and boot). What is notable about this stage is that, A.) if done here, B2G launches at around 5.8s and B.) It successfully runs. Sometimes. There are clearly some dependencies that are not quite guaranteed to be ready if one attempts to launch B2G this early, which could be the subject of a future investigation to see if those dependencies could be moved earlier as well. However as it stands, this only launches B2G around 2 seconds earlier. and there actually was no decrease in overall boot time observed (again dependencies not being respected comes to mind as an explanation).  
Line 124: Line 126:
One will note that in the first 13 trials B2G tries to launch, crashes, and then relaunches at around 12s, whereas it starts fine for the last 3. Seen below is a sample of a run in which B2G crashes vs. not
One will note that in the first 13 trials B2G tries to launch, crashes, and then relaunches at around 12s, whereas it starts fine for the last 3. Seen below is a sample of a run in which B2G crashes vs. not


[[File:lesswl-bootchart.12.png|600px|Crashing]]
[[File:lesswl-bootchart.12.png|750px|Crashing]]
[[File:lesswl-bootchart.13.png|600px|Not Crashing]]
[[File:lesswl-bootchart.13.png|750px|Not Crashing]]




Confirmed users
125

edits

Navigation menu