Hey Vivien, looks like you stumbled upon a bug in our memory log generation. I have a patch in-flight [1] to fix that and then the memory numbers should be reported correctly.
Dominic, other than the device information there, nothing should be that different from a local Flame, except for the fact that the devices on Jenkins have the "light" reference workload installed. Jenkins uses the same steps to run Raptor tests that you should use locally [2], so the Flames should be very similar. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1170533 [2] https://developer.mozilla.org/en-US/Firefox_OS/Automated_testing/Raptor#Getting_Started Thanks, Eli Perelman On Tue, Jun 2, 2015 at 3:58 AM, Vivien Nicolas <[email protected]> wrote: > That sounds awesome. > > For master: > In the memory section there are a few strange things: > - FM Radio and Test Startup Limit USS are 0. That sounds crazy. > - Phone/Contacts RSS is close to 1.60mb that sounds crazy too. > > The measures sections is empty. > > > Thanks for this work. > > On Tue, Jun 2, 2015 at 2:52 AM, Eli Perelman <[email protected]> > wrote: > >> Hello everyone, >> >> As has just been written up by Rob Wood, Raptor is now actively being run >> against Gaia pull requests in order to prevent larger regressions from >> sneaking in and degrading performance. This is a great proactive measure to >> keep our device performance at the forefront of development and is a great >> achievement. I also wanted to inform everyone that we are also improving >> automation around performance regressions that occur post-commit. >> >> For the past two weeks, we have had a couple script jobs in place that >> query the cold launch data from the Raptor dashboards [1]. Every day at 7AM >> PT, the scripts fetch all data from the previous 7 days and are run through >> some re-tooled graph server code (ported by Will Lachance) to detect any >> performance regressions. If any regressions are found, Raptor will file >> appropriate bugs in their respective Bugzilla components, or in the more >> general Performance component if a regression occurs in multiple >> applications. In fact, Raptor found its first regression today, if you >> would like to see an example of what is generated [2]. >> >> >> >> *Call to Action* >> If you care about the performance of a particular component, e.g. you are >> an app owner, peer, or just <3 keep things fast and under control, I >> encourage you to subscribe in Bugzilla to your respective components. If >> you only care about the performance of the Clock app, feel free to watch >> just bugs in the Clock component to keep the noise down. If you want to >> know more about any performance issue that Raptor finds, you can either >> watch the Performance component in Firefox OS, or maybe create a saved >> search for all bugs filed by [email protected]. Every regression that >> Raptor finds is tagged with the "perf" and "regression" keywords, and the >> bugs contain relevant information about the Gaia and Gecko commits that >> were involved with the regression to aid in backouts or bisection. >> >> If you have a regression come up in an area of your concern, please >> triage it quickly and lets keep and improve the performance of Firefox OS! >> >> [1] http://raptor.mozilla.org >> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1170149 >> >> Thanks! >> >> :Eli Perelman >> >> >> _______________________________________________ >> dev-b2g mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-b2g >> >> >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
