While QA is doing bisect, here're the things I noticed from today's profile of launching SMS [1]. Remember it's just one profile and does not mean the spike on datazilla is because of those, still need further check:
1. Bug 1125713 <https://bugzilla.mozilla.org/show_bug.cgi?id=1125713> sends lots of loadprogresschanged to parent 2. ~200ms atc_changeTransitionState() in parent process, ~100ms write() could be bug 1137124 <https://bugzilla.mozilla.org/show_bug.cgi?id=1137124> 3. A very long nsFreshDriver::Tick (~140ms) after awm_switchApp() in chrome process Above three occupy B2G main thread and block the sync IPC SendClipboardHasText in child process (~400ms), note there's another sync IPC SendPRemoteSpellcheckEngineConstructor could also be blocked. 4. ~300ms settings_init() in child process, 1 is part of the reason [1] http://people.mozilla.org/~bgirard/cleopatra/#report=c4eb8234dd65f83c2daf35da851a328003c5f1ed Gaia: c4835abe080b20aaec6e736ad6f4a74c444c244c Gecko: https://hg.mozilla.org/mozilla-central/rev/fd8e079d6335 Device: Flame 1024MB v18D Ting On Mon, Mar 9, 2015 at 11:47 AM, Bobby Chien <[email protected]> wrote: > Hi Julien and All, > > Please follow bug 1132515 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1132515> for more > information. QA already did bisection based on pvt inbound build. Range > already be reduced in few hours range. However, we need more bisection on > changeset based. Since changes of Jan 26, these changes increse startup > time and deviation. > > ----- > *Bobby Chien* > Sr. Engineering Project Manager > Firefox OS, Mozilla Corporation > > Julien Wajsberg <[email protected]> 於 2015年3月7日 上午12:06 寫道： > > > https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=60&test=startup_%3E_moz-app-visually-complete&app_list=calendar,clock,communications/dialer,fm,sms&app=calendar&gaia_rev=d5dc2f2014ae7bfb&gecko_rev=bab6bcc71cb0&plot=avg > > We clearly see we have the same pattern in all apps. So this is either > in System, Gecko, or Gonk. > > In Sms we have 300ms more now than on the January 25th. In Dialer 150ms > more. > > Who can investigate this? > > > Le 27/02/2015 10:52, Julien Wajsberg a écrit : > > I feel like this was not the only issue. > > If I look at the Dialer line which is quite stable, we clearly see it's > still not back at the level of speed from before 1/25. We see the same > on other apps too. > > We also see a small pike from yesterday .. but nothing interesting in > gaia nor gecko :( > > > Le 26/02/2015 21:47, [email protected] a écrit : > > The regression may have been introduced by bug 1121871 and fixed in bug > 1134762 which undid most of that change. These two changes had a rather > large impact on graphics behaviour and painting, and the timelines seem to > match what you're seeing. > > On Thursday, February 26, 2015 at 2:32:25 PM UTC-5, Bobby Chien wrote: > > Hi All, > > > When I monitor datazilla in this week, I found numbers are stable since > 2/25 and 2/26. Anyone know how we fix the problem, or any code landed this > week? > > > > https://datazilla.mozilla.org/b2g/?branch=master&device=flame-319MB&range=60&test=startup_%3E_moz-app-visually-complete&app_list=calendar,camera,clock,communications/contacts,communications/dialer,email%20FTU,fm,gallery,music,settings,sms,video&app=gallery&gaia_rev=bc052c237e0371e8&gecko_rev=c4a040299b9e&plot=avg > > > Thanks, > Bobby. > > > > > > > > > ----- > Bobby Chien > Sr. Engineering Project Manager > Firefox OS, Mozilla Corporation > > > > > Alexandre Lissy <[email protected]> 於 2015年2月13日 上午1:47 寫道： > > Le 12/02/2015 18:41, Gregor Wagner a écrit : > bent made some changes to indexedDB. Anything that landed around 1/27/15? > > And we fixed preloading mozSettings when forking a couple of days before. > > If you can analyze the regression locally, may be worth to revert the > patch that fixes preloading of mozSettings (dom/ipc/preload.js) > > > On Thursday, February 12, 2015 at 9:30:11 AM UTC-8, Eli Perelman wrote: > In looking at some of the results, it appears that most of the runs have > regressed slightly with the initial run spiking quite a bit. Like Gandalf > had said, this is really noticeable in apps like SMS, Gallery, Music, > Video, and Contacts. This makes me wonder: does anyone know of any changes > to IndexedDB that may have caused this regression? > > Thanks, > > Eli Perelman > > > > On Thu, Feb 12, 2015 at 11:12 AM, Eli Perelman <[email protected]> > wrote: > > > I have filed a bug to track this regression [1]. Nothing has changed in > the way make test-perf gathers its metrics, but I was aware of an issue in > the lab where devices where white-screening and causing tests to hang. I'm > not sure if that was the cause of some of the noise, but I imagine if the > regression persists than it is more likely commit related. > > Performance issues which affect several apps could either be either Gecko > or Gaia related. First steps are to get a regression range for Gecko and > Gaia, run the performance tests against each of the 4 configurations of > Gecko+Gaia (first-known bad, last-known good of each), and then bisect the > appropriate offender. Then we can determine which patch to back out. > > David, if you would like my assistance in showing you how to get this > started, feel free to ni? me in the bug I created and I will help you out. > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1132515 > > > Thanks, > > Eli Perelman > > > > > > On Tue, Feb 10, 2015 at 2:38 AM, Julien Wajsberg <[email protected]> > wrote: > > > > > > > > > I know one of them is bug 1115796 and bug 1128505 > > is here to make this less noticeable. But I don't know for the other > > increases :/ > > True, there seem to be a much greater regression, above 100ms. The bug you > mentioned landed on Jan 20th and gives ~30ms. > > > > I'm not sure if it's that related. > > > > Sorry, I was not saying it was related to _this_ spike but I wanted to > > give all context :) > > > > > > > > > _______________________________________________ > > dev-gaia mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-gaia > > _______________________________________________ > dev-gaia mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-gaia > > > _______________________________________________ > dev-gaia mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-gaia > > _______________________________________________ > dev-gaia mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-gaia > > > > > _______________________________________________ > dev-gaia mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-gaia > > > > _______________________________________________ > dev-gaia mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-gaia > >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
