Raptor's performance tests also use 319MB as it is the only real baseline we tracked from v2.2. In order to compare the performance between the two branches of v2.2 and v2.5, we need a comparable baseline. We have been aggregating data for the Flame 1GB for future comparisons, but I would suggest proposing a new baseline sooner rather than later so Raptor can begin to aggregate data against that device and make it trackable between branches.
Thanks, Eli Perelman On Tue, Sep 15, 2015 at 12:48 PM, Martijn <[email protected]> wrote: > On Tue, Sep 15, 2015 at 6:32 PM, Naoki Hirata <[email protected]> wrote: > > > > I believe we still do care. > > > > Running Engineering build will make some difference as the 319 MB takes > into account the camera but not Marionette (adb + devtools) which the > engineering build runs. > > > > Having said that we run automation tests through jenkins, I'll check > with mwargers in regards to the issue to see if he already filed a bug or > not. > > > Yes, we're running the Gaia UI tests with the 319MB configuration and > we have various tests that are failing (intermittently) and disabled > because they just don't work with 319MB: > 1172167 [Flame][Cards View] Cards view loses the list of recently opened > apps > 1176502 Failure in test_homescreen_column_layout.py on the Flame > device, because Settings app gets killed > 1178859 test_browser_bookmark.py: "IOError: Connection to Marionette > server is lost." > 1181344 [Window Management] Settings will be a blank white screen when > returning from the "Built-in Keyboard" settings > 1188080 test_rocketbar_offline_behavior.py: "NoSuchWindowException: None" > 1189262 Failure in test_browser_share_link.py using Flame 319MB > 1204280 [Flame] Intermittent failure in test_sms_contact.py in > tap_send_sms using Flame 319MB > 1188603 [Settings][Ringtones] Share activity closes when attempting to > add custom ringtone > > I think these bugs need to be fixed, because they stand for lost > functionality in those low memory conditions. > > All the bugs currently out there, regarding supporting 319MB memory > configuration: > > https://bugzilla.mozilla.org/buglist.cgi?list_id=12549261&status_whiteboard_type=allwordssubstr&query_format=advanced&status_whiteboard=[319MB-Flame-Support] > > Regards, > Martijn > > > > > > > > We still have not resolved the series of initial bugs going into 2.5/3.0: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1155854 > > https://bugzilla.mozilla.org/show_bug.cgi?id=1162535 > > > > On Tue, Sep 15, 2015 at 2:13 AM, Ting-Yu Chou <[email protected]> wrote: > >> > >> A bit off-topic. > >> > >> Raptor [1] just records a serious memory regression though, not sure is > it related to the issue you see. > >> > >> Ting > >> > >> [1] > http://raptor.mozilla.org/#/dashboard/script/apps-memory.js?device=flame-kk&branch=master&memory=319 > >> > >> On Tue, Sep 15, 2015 at 4:56 PM, Gabriele Svelto <[email protected]> > wrote: > >>> > >>> I was doing some testing in the past few days on a Flame using the > >>> 319MiB memory switch and found that our core apps are now almost > >>> unusable on it. Opening a single app seems to end up killing the > >>> homescreen and keeping two open at the same time is almost impossible. > >>> > >>> So I've got two questions: the first one is, did we significantly > >>> regress memory consumption again? Or is it just gecko having grown > >>> significantly in the past few weeks making our minimum process size > >>> larger? The second question is obviously: do we still care about 256MiB > >>> devices? Because if we still do then it looks like we're not in a good > >>> spot for a 2.5 release running on those. If we don't care I suppose > it's > >>> fine though we should still keep our memory consumption under control. > >>> If we move our minimum to 512MiB we'll have plenty of room and this > >>> might cause us to regress even further almost without noticing (*). > >>> > >>> I'm running an engineering build BTW, but I don't think this should > make > >>> much of a difference. > >>> > >>> Gabriele > >>> > >>> *) Unless the screen has a rather high resolution, in which case 512MiB > >>> might still yield only a small amount of usable memory for apps as most > >>> of it will go to the framebuffer and accompanying structures (layers & > co). > >>> > >>> > >>> _______________________________________________ > >>> dev-fxos mailing list > >>> [email protected] > >>> https://lists.mozilla.org/listinfo/dev-fxos > >>> > >> > >> > >> _______________________________________________ > >> dev-fxos mailing list > >> [email protected] > >> https://lists.mozilla.org/listinfo/dev-fxos > >> > > > > > > _______________________________________________ > > dev-fxos mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-fxos > > > _______________________________________________ > dev-fxos mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-fxos >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
