I guess the question is: Why is the child process's event loop busy when my <script defer> starts running?
It's possible that the main process is taking CPU time from the child process, and that's why it appears that the child process's event loop is busy at that point in time. But if you want to know the answer for sure, you'd have to profile. We have tools that will let you get a fairly complete picture of what's going on. On Thu, Apr 18, 2013 at 3:15 AM, James Burke <[email protected]> wrote: > I am investigating email app cold startup time. If the code puts > something in the event loop via a postMessage or a very short > setTimeout during the startup of the app, it could be delayed as much > as ~130-150ms for the first item, and often a follow-on item after > that one can take ~20-50ms. This can add up to around ~200ms delay for > app logic to complete. > > This is using BRANCH=v1-train VARIANT=eng b2g builds for the unagi > device. I am using a build from code pulled around 4pm April 16 > Pacific time. > > I did a test using this app: > https://github.com/jrburke/gaia/tree/eventloop/apps/eventloop > > Specifically, this test.js: > https://github.com/jrburke/gaia/blob/eventloop/apps/eventloop/test.js > > Some sample output: > FAST TICK DONE IN: 134.7045879999996 > DEFAULT SET TIMEOUT DONE IN: 52.978517000000465 > 0 SET TIMEOUT DONE IN: 18.46313299999929 > 4ms SET TIMEOUT DONE IN: 6.042480000000069 > > After the page has loaded, the times to complete the callbacks are in > line with expectations, it is just during the startup phase where the > time delay is really large. > > I did a run by disabling the screenshotting in gaia, and that seems to > help the second, ~50ms case, removing that delay, but the first one > still remains: > > FAST TICK DONE IN: 144.4091789999993 > DEFAULT SET TIMEOUT DONE IN: 1.3427740000006452 > 0 SET TIMEOUT DONE IN: 0.6408689999998387 > 4ms SET TIMEOUT DONE IN: 4.638672000000042 > > I can appreciate that the answer may be "the platform is still > starting up the mozbrowser, this is expected". > > However, I was hoping that I would not have to special case a sync > path for some generic code used for dynamic async loading of segments > of the app, just for the first card setup. Even with a special sync > path, it seems like I just shift around the ~150ms wait to another > point in the app, and still seems to get in there before the user can > interact with the first card. > > It also seems odd because the page is pretty simple (no CSS, l10n), > and the script is set as "defer", so I would have expected that the > script was one of the last things run as part of the app load. > > James > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
