I presume James is correct about the v2.2 launch time of Email, as it had previously been fast, but when we captured the official v2.2 numbers, had increased significantly, but has since been fixed. I'm sure changes have been uplifted to v2.2 that may have resolved that issue.
For the first startup, that isn't an issue with Raptor. Raptor primes every application before actually capturing any metrics to combat any variation the first run of an app has with the subsequent runs. Eli On Fri, Oct 2, 2015 at 11:33 AM, James Burke <[email protected]> wrote: > On Fri, Oct 2, 2015 at 8:54 AM, Gareth Aye <[email protected]> wrote: > > muy cache! > > > > On Fri, Oct 2, 2015 at 11:37 AM, Wilson Page <[email protected]> wrote: > >> > >> Wow! Can email share what changes they made to get such a big > improvement? > > Email does use a startup cache, but also uses the cache in 2.2. I > suspect some other factor involved in the high 2.2 number, it should > not be that high, previous releases to 2.2 were not that high with the > same cache mechanism. > > We did change some of the startup logic in the 2.5 timeframe, but that > was more about trying to better reason about startup with the async > setMozMessageHandler entry points vs tuning for performance. The > startup cache in 2.2 was stored in cookies, 2.5 now uses localStorage, > which is slightly slower than a cookie store, but allows us to cache > more entry points, and is saner to deal with. > > It could be that the very first startup, which does not have a cache > to use, takes long enough to skew the numbers high on 2.2? Testing > manually just now on a flame flash of a 2.2 engineering build, running > at 319MB, the cache is in effect in 2.2 and feels as fast as master, > near instant UI display from cache. > > As I recall, the email numbers for 2.2 were in the range of the 2.5 > numbers for a while, but at some point changed, but we were not > pushing email changes to 2.2 for a while, already focused on 2.5 code, > so did not feel the urgency to investigate, figured it was something > that would be corrected on its own via something changing in gecko for > example. > > If it is an issue to get to the bottom of the higher number in 2.2 I > can look more, but I felt resources were better spent on the current > master efforts since manually testing still indicated 2.2 was fast > with its cache implementation, and larger changes to 2.2 seem > unlikely. > > James >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
