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

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. 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.

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 made to occur any earlier. But 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).  

[http://people.mozilla.org/~jbailey/v121-2-lesswreckless/ Related Data]. Not as many trials were done because these were just cursory feasibility tests.

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. In particular one can search for the string OPTBOOT in the kmsg.N and logcat.N files for a look at the timings of a few important points.