What makes it feel slow/broken? The Marketplace app takes long to start up after device startup or reset. Timed consistently around 6.5 seconds on Unagi running Dec. 6th nightly. David Clarke to provide more accurate, recent numbers on Otoro. Did it prevent you from doing what you wanted? Why? Along with making phone calls, SMS is one of two core communications methods used in our target launch market. It's critical that this experience be as fast as possible. While 3.0 seconds isn't horrendous, any gains we can make here would be important. How does this make you feel? [ ] :) I feel happy about it [ ] :| Meh [X] :( I'm upset [ ] >:O I'm angry Device: Original numbers from Unagi, Dec. 6th nightly. David Clarke to get Otoro numbers. Details: B2G on Unagi: 6.5 seconds Android ICS 4.0.4 on Otoro: need to find out David Clarke to provide updated B2G on Otoro numbers. Bonus: can you attach a video of the problem? See metabug 814981

Potch has been doing some work on the appcache side for this. Maybe he has some insight on what we could do improve perceived perf on the marketplace app on start-up.

Is appcache usable? I thought it was too slow to be used (but I don't have a bug).

The marketplace's size has been decreasing. We should continue to track it as we're doing now. http://marketplace-size.appspot.com The Fireplace project is attempting to alleviate a lot of the issues surrounding this by packaging the Marketplace. What is the action required for this bug? What is the end goal? Is there a specific startup time that we're looking to achieve or is this bug a tracker for our efforts to reduce the MP's overhead?

(In reply to Matt Basta [:basta] from comment #4) > The marketplace's size has been decreasing. We should continue to track it > as we're doing now. > > http://marketplace-size.appspot.com > > The Fireplace project is attempting to alleviate a lot of the issues > surrounding this by packaging the Marketplace. > > What is the action required for this bug? What is the end goal? Is there a > specific startup time that we're looking to achieve or is this bug a tracker > for our efforts to reduce the MP's overhead? A lot of these "startup" bugs were filed as common complaints by our partner + UX issues. The end goal I guess we need to talk to product about - what is our target startup time on device on a typical network in our target markets? Btw - for tracking, you guys should talk to the ateam to get yourself added to https://datazilla.mozilla.org/b2g/. That will give you nice numbers to see how you guys do on startup perf.

(In reply to Jason Smith [:jsmith] from comment #5) > Btw - for tracking, you guys should talk to the ateam to get yourself added > to https://datazilla.mozilla.org/b2g/. That will give you nice numbers to > see how you guys do on startup perf. Thanks. It looks like we are added and we are the fastest loading app at this point. I'm going to close this bug since we've made a lot of improvement since it was filed months ago. We can follow up with the target startup times in email/meetings.

Okay. Strange that it's coming up as that fast though - probably measuring by first paint then. I'll talk with jgriffin about this to find out why our numbers are showing this to be fast.