In the 12/4 weekly meeting , we discussed a gradual performance regression in page load times over the past few months, discovered by comparisons to Chrome and Eideticker. Currently, we can track page load time with the full product by loading a page and comparing the result with older versions. This is a good start but we should also create a method of determining how much page load performance is impacted by Android-specific code so we can find regressions there. For example, one suggestion is to build Gecko into a standalone app (perhaps using GeckoView) that will startup and immediately load some web page, and compare this to our full app results (ex: Eideticker). There may also be work to be done on profiling and seeing where we might be slow, perhaps independently from whether we have regressed or not. For example, there may be some inefficiencies where code is called multiple times (, ). Finally, there is work to be done on page load performance that is not a direct regression, such as predictive lookup and prefetching (see  and its blocking bugs). : https://wiki.mozilla.org/Mobile/Notes/04-Dec-2013 : https://bugzilla.mozilla.org/show_bug.cgi?id=924712 : https://bugzilla.mozilla.org/show_bug.cgi?id=941844 : https://bugzilla.mozilla.org/show_bug.cgi?id=943475
Adding a few of the redirect bugs that make GlobalHistory do less work during a pageload. Less writing to the DB means more time for networking. Also adding the Seer pageload regression.
I think this bug is/has morphed into the tracking bug for the page load performance project, so gently recasting it as such, under the assumption that some of "improve" will be "find and fix regressions". mfinkle, do we still not track meta bugs? Is the weekly meeting enough spinning for these project 'plates'?