864414 - [email] Cache default account, default inbox, and its most recent messages in cookies to improve startup time

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[James Lal [:lightsofapollo]]

Starting the worker and loading content inside of it prior to showing messages has a non-trivial cost we can bypass most of this by optimizing for showing messages ASAP then load entire back-end in the worker so we can sync messages.

Comment 1

[Dylan Oliver [:doliver]]

jrburke, can you take a look at this one? :lightsofapollo has to jump over to Calendar for a bit.

Comment 2

[James Burke [:jrburke]]

Tried an initial experiment of collecting select messages received from the worker and caching them persistently in the front end. Then when a cold restart, the cached messages are replayed for main-frame-setup. Time to seeing messages went from close to 3 seconds down to about 1.5 seconds.

The approach is very hacked up at the moment though, not all the important things are cached yet, and need to work through any edge cases, and also get a review to make sure the change is not too disruptive. 

It also may make the "time to load" number a little bit longer, but greatly improves the "time to first messages" display. So it is probably worth the tradeoff, particularly since "time to load" is misleading anyway.

Comment 3

[James Burke [:jrburke]]

Work in progress compare view:
https://github.com/jrburke/gaia/compare/master...bug864414_fastmessage

For gelam:
https://github.com/jrburke/gaia-email-libs-and-more/compare/master...bug864414_fastmessage

The gaia one has some extra changes in ttlview, window_manager and things like message-cards, but those would not be there in the final pull request. Those are my hacky changes for measuring "app is now usable".

App-usable in this version is around 1800ms (some runs dip to 1600-range), vs 3000ms before. "time to load" is slightly higher, more like 1000ms, but much better on "usable" number for when an account is configured.

This approach uses a cache of messages received previously from the worker and stores them, that's right, in a cookie! I did a special encoding for the cookie value instead of a generic encodeURIComponent so that we had enough cookie space to store 5 records. If I used encodeURIComponent, it got really hard to just get one in there, along with the account and folder messages. So, the selective encoding helps give more space, but need to test it some more. With this, on my test account, the cookie storage was around 3.1KB, and we have a max of up to 4KB.

With this change, I removed the old hasAccounts cookie check, since that info is now encoded in this new cache. The nice thing with any of these changes, if the cache is bad for some reason, the user just gets the slower loading behavior, but it still works.

Another approach would be to try to load the mailslice code on the main thread. However, it seems like that approach would still need to have the "clean up the slices when we get real messages from the back end" in this changeset and means more JS code loading on the main thread, and it seemed to be tricky to sort out having two postMessage inputs to MailAPI and wiring up to the indexedDB access. We also have a chance to avoid the 150ms event loop dead zone by doing more work as synchronously as possible up front. I'm open to other ideas though.

Things that still need consideration in current state of the code:

* The slice cleanup actually fakes a splice to remove the old cached values if they do not match. This seemed the cleanest as it also then cleaned up the card display. However, there is a momentary flash of "no mail in this folder" message while that happens. I want to make that smoother.

* You will only notice the speed on the second cold start after having an account. So: start app, configure account and have it load up messages. Close app, relaunch. This relaunch will still be slow as before. However, if you close it and relaunch after that, it shows the faster behavior. I expect this happens because the cache state when the headers come in is not matching expectations. I am hoping it is just checking for extra state to sort that out.

Once those two items are sorted, then I'll feel better about doing a real pull request. Linking to the changes early though in case I am missing some problems with the current approach.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

Those are amazingly improved numbers!  Bravo!

If the tests at http://browsercookielimits.x64.me/ are not broken, we can cram more than 4k's worth of data in our cookie cache.  I ran it for my stock firefox, and it says:
9:9:2.960: Max Cookies with Character Length 4097 and character "1": 150

So for simplicity, maybe we want to use 1 cookie per message in the list?  Even on IE it looks like we can get up to 12k worth of data these days...

Comment 5

[Dylan Oliver [:doliver]]

Nominating for leo -- this is the primary bug we're working on to address 860605.

Comment 6

[James Burke [:jrburke]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9443

Pointer to Github pull-request

Comment 7

[James Burke [:jrburke]]

Comment on attachment 742897 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9443

Introduces a cache of messages from back end, stored in a cookie to speed up initial render. With this change:

* Removes extra files from being loaded for back end on main thread, now just main-frame-setup, since it creates MailAPI synchronously now, with the cache data at first.
* Tested upgrading from maste with this change: user sees a brief flash of the New Account screen on first upgrade, but then changes over to message list once accounts are really detected. From then on, the new cache is used for faster speed up.
* Also tested two accounts configured (one imap, one activesync). Cache works correctly. The back end seems to change the order they are listed in the account splice on second reboot. The cache updates to match. 

This change shaves a bit more than a second off the time to see message list.

I tried another experimental change where the message list card is not rendered at all until first messages, and about another 200-300ms are saved (currently we hit the messge list card 2-3 times on app boot up). However, it means a longer visible "white page" flash, so opted not to do that for this patch. Hopefully Bug 863499 lands some load event delay mechanism so that the screensot can be held a bit longer, and with that, we could pick up the extra gain since the white flash will be hidden by the app screenshot.

This change will increase the "time to load" number tracked in datazilla by a bit though. However, since that measurement was a bit misleading anyway for the mail app (user would not see messages until a good time after that number), I believe the tradeoff is worth it. If a solution for 863499 lands, then it would be possible to use that to get a better measurement of when the app is actually usable.Use cookie-based cache of back end messages from worker to speed up initial render of message list.

Includes the change from GELAM patch:
https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/190

Comment 8

[Wayne Chang [:wchang]]

Triage - blocking per comment 5, blocking a leo blocker.

Comment 9

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 742897 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9443

Provisional r=asuth with nits fixed.  James is doing some additional testing and fixing, so there might be another few fixes coming that we might want to wait for before landing.

Comment 10

[James Burke [:jrburke]]

Fixed in gaia master:

Pull: 
https://github.com/mozilla-b2g/gaia/pull/9443

Commit:
https://github.com/mozilla-b2g/gaia/commit/5132f3cdf62ca1065591cc69488d61cdd6ca97b0

GELAM change:

Pull:
https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/190

Commit:
https://github.com/mozilla-b2g/gaia-email-libs-and-more/commit/dc43c9cd806144d3a0ae310dcf29b03ce224b551

Comment 11

[Andrew Sutherland [:asuth] (he/him)]

:jrburke accidentally cleared the leo+ flag in comment 10, it'd be great to get this back so we can uplift to v1-train.  We believe this to save approximately 1200ms at startup (3000ms => 1800 ms), which is nice, so don't go changing your minds!

Comment 12

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 5132f3cdf62ca1065591cc69488d61cdd6ca97b0 to:
v1-train: 8560da0c79b293cb421e33dc9b99f2afc12b6fdf

Comment 13

[Tracy Walker [:tracy]]

Initial email startup is noticeably less than 3 seconds
verified fixed on Leo with:

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/0c71cbc5fe0c
Gaia   a7b0810580afc734f3d5e441914fe895f9c1923e
BuildID 20130508230207
Version 18.0

Comment 14

[Andrew Sutherland [:asuth] (he/him)]

(Updating subject for clarity.  What we did was actually bug 814267 rather than the original subject. Going to dupe that bug to this one now.)