On Tue, Aug 11, 2015 at 5:17 PM, James Burke <jbu...@mozilla.com> wrote: > https://github.com/jrburke/fxos-startup-test > > There are three variations mentioned in the README, each with a > profile.sh capture "Profile" link:
I did a pass at the "Regular" profile and put the notes here: https://github.com/jrburke/fxos-startup-test#profile-notes and duplicated below for ease of reference. In short, it seems like an approach like the one used in the test app, with a transparent background and a template element for the body content, seemed to avoid any sizable layout or rendering work during initial page loading and the point where the app JS constructs the view. So, seems like we can hold off on any new browser APIs for now, and use app-level constructs to group changes that might trigger layout before insertion in the DOM. I welcome other people's inspection of the profile though. Perhaps I did not capture all the relevant info. The b2g/gaia code around launching an app has changed since last doing a profile like this (at least a year ago), so those changes and using the app approach in the test app seem to be sufficient for now. It might be nice to reduce some other startup costs but those seem to be more in the realm of gaia's control. --- 208030ms is the firstLoadURI marker, so going from that marker as the start point. Dropping the **208** prefix for the numbers to help make it easier to see the relative differences. * **Start**: 030 - firstLoadURI * **End**: 434 - The JS in startup.js that sets up the view. Layouts after this point are expected, not part of this test. The goal is to find savings between firstLoadURI and the startup.js point. Timeline: * 034-045 - 11ms: getAppInfo @ AppsService.js:110 * 058-223 - 165ms: epoll_wait on Content row, the GPU row has around notable 8 notable Composite entries, each around 4ms, some very small (less than 1ms) Composite entries too. Hypothesis: related to the app icon zoom in effect when tapping on an app icon from the home screen. * 239-284 - 45ms: Some script work relatied to user customizations and CSP: * this.UserCustomizations.observe() @ UserCustomizations.jsm:297 * getCSPBYLocalId() and getAppBYLocalId(), both in AppsService.js * 297-362 - 65ms: nsInputStreamPump:OnStateStop: some sort of IO? * 366-389 - 23ms: RunScript related to BrowserElementChild.prototype._metaChangedHandler @ BrowserElementChildPreload.js:562. * 389-433 - some IO work/evaluation of cards-message-list.js, a script in the page, and 7ms spent in nsStyleSet:FileRules. * 434: Start of startup.js view work. A quicker evaluation of the "display none body" and "display none html" profiles show they do not perform any faster than the "regular" one, and have a similar shape between the firstLoadURI and the startup.js work. Looking at that profile does not seem to indicate sizable wait time related to layouts or renders before the app JS constructs the view. There does not seem to be a need for extra APIs in the browser for controlling layouts or paints using this approach: * Set the background-color for the body to be transparent. * The body content consists of a `<template>` element with the initial content. It can include custom elements, but they are inert given the `<template>` usage. * Async load the scripts that will provide the implementation of the custom elements. * Once all the elements have been registered, document.importNode the body template's content, and append to the body. At this point the content becomes visible, and layouts and reflows occur. It might be possible to optimize some of that layout work, although this test is fairly straightforward: some innerHTMLs done in some custom element createdCallback steps, and no other dynamic JS work done after that. --- James _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
