Contacts launch needs to be further optimized. We observed that the sorting for 500 contacts is taking around 500ms. Is there any way that we can do it asynchronously in the background while launch in parallel. Currently sorting seems to be completely blocking all other operations and we donot see CPU spending on any operations. Is there any we can hash it in DB instead of sorting during every launch?

Current time seems to be approximately secs to launch with 200 secs. It takes 1.5 secs to launch the same Android. It would be good to see Contacts launching in 1.5 to <2 secs with 500 contacts in FFOS.

Current time seems to be approximately 3 secs to launch with 200 secs. It takes 1.5 secs to launch the same Android. It would be good to see Contacts launching in 1.5 to <2 secs with 500 contacts in FFOS.

(In reply to godavari@codeaurora.org from comment #0) > Contacts launch needs to be further optimized. We observed that the sorting > for 500 contacts is taking around 500ms. Is there any way that we can do it > asynchronously in the background while launch in parallel. > Currently sorting seems to be completely blocking all other operations and > we donot see CPU spending on any operations. > > Is there any we can hash it in DB instead of sorting during every launch? We already do this with bug 836519. I think we only need to use it from gaia now.

(In reply to Gregor Wagner [:gwagner] from comment #3) > We already do this with bug 836519. I think we only need to use it from gaia > now. Good point Gregor, our problem is that bug 836519 is a leo bug, not a tef+, which means it wasn't uplifted, and as far as I know this was decided cause time concerns. If we want to use this fix we will need to rethink the risks of adding bug 836519 and any gaia modifications for v1.0.1 Cheers! F.

(In reply to Francisco Jordano [:arcturus] from comment #4)> > If we want to use this fix we will need to rethink the risks of adding bug > 836519 and any gaia modifications for v1.0.1 > Right. Who makes this call? mvines decided this is tef+.

Ok just checked with gal. We should uplift the required patches. Lets get a list of all required patches first. Reuben, can you link to the required gecko patches? Francisco, do we have a gaia patch that's ready?

So far :albertopq was trying the patch but as long as this wasn't going to be ready for 1.0.1 we didn't go forward. We will take a look and will bring those changes back. Cheers!

(In reply to Gregor Wagner [:gwagner] from comment #6) > Reuben, can you link to the required gecko patches? Bug 836513, bug 837917 and bug 836519. I advise uplifting bug 844274 as well, since it simplifies the code and fixes an intermittent orange, reducing the risk. Bug 844558 has further optimizations, but hasn't even landed on m-c so I don't think we can take it.

I've been playing around with the new api and we will need to do some changes on the frontend. Right now the first contact returns pretty quick (nice job folks!), but we will need to recode the way we render contacts, as waiting for all the contacts to come from the cursor is slower than asking for all of them without the cursor. With that said we will need to start appending contacts to the list earlier. Another interesting thing is that we need 1.3 seconds to load the config.json or either a 1 second when reading from indexeddb to check what's the order we are going to ask for. We can try to do a an early read of this value, as early as possible, in order to not to wait that time since we start asking for contacts. Cheers!

(In reply to Francisco Jordano [:arcturus] from comment #9) > I've been playing around with the new api and we will need to do some > changes on the frontend. > > Right now the first contact returns pretty quick (nice job folks!), but we > will need to recode the way we render contacts, as waiting for all the > contacts to come from the cursor is slower than asking for all of them > without the cursor. We should do that anyway, but getting all contacts shouldn't be slower with cursors. See the timings in bug 844274 comment 6.

(In reply to Reuben Morais [:reuben] from comment #10) > We should do that anyway, but getting all contacts shouldn't be slower with > cursors. See the timings in bug 844274 comment 6. Nevermind, I was confused, I only just now landed that bug in b2g18, so if you update to grab that change, getting all contacts should be as fast or faster than find().

Definitely don't wait until you have all contacts. At the very least start rendering contacts once you have enough to fill the screen. The goal should be to make things fast, not just faster than what we have now. (In reply to Francisco Jordano [:arcturus] from comment #9) > Another interesting thing is that we need 1.3 seconds to load the > config.json or either a 1 second when reading from indexeddb to check what's > the order we are going to ask for. I don't really follow this comment. What's in config.json or indexedDB that you need to load? Is it the user settings which control which order to render things?

> (In reply to Francisco Jordano [:arcturus] from comment #9) > > I don't really follow this comment. What's in config.json or indexedDB that > you need to load? Is it the user settings which control which order to > render things? Exactly, we need to wait till we know the order for the contacts (this is a user setting) to ask for the correct order to be returned by the api. Cheers.

We have to uplift the blocking patches. Ryan can you take care of it?

This meta bug is marked tef+ by partners, so we'll make a valid assumption that blocking bugs are tef+ as well.

For this to be a blocking bug we need some specific success criteria (i.e. startup time target and methodology). It cannot be resolved FIXED without a goal being met.

ni? from Surya on ^^^

For Contacts app launch latency, the target is 1.5sec. The latest measured value is 2.2sec. Method of measurement. - High speed camera is used to capture the frames at 240fps. The latency is measured as the time duration between the highlight of icon to Contacts App completely rendered the frame.

Thanks for the update. These numbers are for 1.0.1? How well do they correlate to the startup times as currently reported by the device (i.e. time to load under developer info)?

Yes, 1.0.1

Is this really blocking given https://bugzilla.mozilla.org/show_bug.cgi?id=851126#c1? :)

Yeah, still blocking as we're looking to achieve ~1.5ms app start time with 500 contacts, as comment 1 describes.

https://datazilla.allizom.org/b2g says we are under 1 sec. How are you measuring it?

ni? for comment 23.

Pinged via email for response.

As mentioned in comment 18 Method of measurement. - High speed camera is used to capture the frames at 240fps. The latency is measured as the time duration between the highlight of icon to Contacts App completely rendered the frame. Our test team uses email configured (with upto 100 mails in inbox). I think datazilla numbers number are without email configuration. Someone needs to confirm. We use the same methodology (configured email from icon highlight to screen update with email entries) to measure latencies in other OSs like Android aswell.

How are we going to reconcile the differences between what datazilla is showing and what's being measured in comment 26?

Datazilla is actually correct. In datazilla, you essentially need to add the "startup_load_time" and the "above-the-fold-ready" (which is only available for the contacts app, and is not very reliable yet). When you add both, you get the delay until Contacts actually displays the first contacts. We may change the "above-the-fold-ready" measurement at one point to be more reliable and to include the time since the startup.

(In reply to Julien Wajsberg [:julienw] from comment #28) > Datazilla is actually correct. > > In datazilla, you essentially need to add the "startup_load_time" and the > "above-the-fold-ready" (which is only available for the contacts app, and is > not very reliable yet). When you add both, you get the delay until Contacts > actually displays the first contacts. > > We may change the "above-the-fold-ready" measurement at one point to be more > reliable and to include the time since the startup. Have we hit our goal then? Surya - please file a new bug with how much we're off by in your most recent v1.0.1 tests.

I think we're not there yet but I know some work is ongoing on this topic.

Pointer to Github pull-request

Comment on attachment 735720 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9088 See performance testing at https://gist.github.com/albertopq/5354452

Comment on attachment 735720 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9088 Incredible boost to the performance. Great job!

Alberto could you post some numbers in terms of performance to have some data to ask for tef+? Thanks!

Dough!, numbers already in comment 32 So worthy to uplift :)

tef- as the improvements in comment 31 to comment 36 are now part of bug 860809

bug 848188 is nearly ready to land, mvines, can you please test performance with that bug (even if it has not landed yet) and let us know if that would be OK to meet our performance targets and if it is not OK, how far are we from them?

Lets get the bug 848188 landed asap and we'll test then.

Hi Michael, this is a improvement that can be test without bug 848188, anyway, this already landed yesterday. So we have both improvements on master. Cheers, F.

Comment on attachment 735720 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/9088 Removing patch from metabug

Sorry guys, reopening as this is a meta bug. Anyway as I commented bug 846895 already landed on master. We can try there. Cheers!

New bug for same issue: https://bugzilla.mozilla.org/show_bug.cgi?id=871823

Should we close this one then ?

+1 to closing it :)

All the interesting information happens on Bug 871823 now. Putting back resolved/fixed.