1013387 - Music Memory Usage Regression

Status: RESOLVED INVALID

(Firefox OS Graveyard :: Gaia::Music, defect, P1)

Description

[Mason Chang [Inactive] [:mchang]]

From datazilla - https://datazilla.mozilla.org/b2g/?branch=master&device=hamachi&range=7&test=music_memory&app_list=system_vsize&app=system_vsize&gaia_rev=d3b16b36d76b5713&gecko_rev=41a54c8add09&plot=median

Music memory usage went from ~207mb to ~230 mb. Regression range:

Good:
Gaia Revision: d3b16b36d76b5713
Gecko Revision: 41a54c8add09

Bad:
Gaia Revision: 84b62184b87e229d
Gecko Revision: 41a54c8add09

Might be related to: bug 1013381.

Comment 1

[Mason Chang [Inactive] [:mchang]]

Attachment: make test-perf memory measurements

I tried using make test perf to measure memory, but I think it is inaccurate. It just opens the app, grabs a snapshot of memory using b2g-info, then reports that data. The problem with the music app is that on app start up, we start scanning the music library, so memory usage goes up. Once we load the library, the GC kicks in and we reclaim the memory. For both the good and bad gaia revisions, the b2g-info memory usage is the same. Just the transient memory usage is different, which isn't quite fair.

If you look at the attached memory reports, we essentially see that the "good" version actually looks worse than the bad version, but both are increasing. Both numbers are also below what datazilla is reporting.

I'm not quite sure this is actually a regression or a measurement error. Investigating.

Comment 2

[Hubert Figuiere [:hub]]

The problem also is in the way we collect memory info: we execute "b2g-info" which mean that it is not instant.

Just FYI.

Comment 3

[Mason Chang [Inactive] [:mchang]]

There were also no music app changes since April 27 - https://github.com/mozilla-b2g/gaia/commits/master/apps/music

Comment 4

[Mason Chang [Inactive] [:mchang]]

Attachment: make test-perf memory measurements, good gaia

Comment 5

[Mason Chang [Inactive] [:mchang]]

Attachment: make test perf memory measurements, bad gaia

Comment 6

[Mason Chang [Inactive] [:mchang]]

Attachment: make test perf memory measurements, older gaia

Comment 7

[Mason Chang [Inactive] [:mchang]]

Closing this bug as invalid from previous memory measurements and comment 1. I went back to an older gaia, revision cf66f95f3e323cd0. Even in the older stable gaia, the system.uss and system.rss increase after every run of make test-perf, but stabilize after a reboot or after the music app finishes reading the app. This is probably an error in the test framework then. Since Gecko did not change between these measurements as well, this is not a Gecko regression.

Comment 8

[Mason Chang [Inactive] [:mchang]]

Attachment: bad.txt

Bad build from datazilla with log - http://selenium.qa.mtv2.mozilla.com:8080/view/B2G%20Perf/job/b2g.hamachi.mozilla-central.master.mozperftest/2825/

Comment 9

[Mason Chang [Inactive] [:mchang]]

Attachment: good.txt

make test-perf log from good revision - http://selenium.qa.mtv2.mozilla.com:8080/view/B2G%20Perf/job/b2g.hamachi.mozilla-central.master.mozperftest/2846/

Confirmed false regression. The order we ran music changed. The good version ran browser, then music. The bad version ran browser, camera, then music. Since make test-perf increases the system.rss size after every run, it looked like a memory regression.

Comment 10

[Mason Chang [Inactive] [:mchang]]

Sorry, the good revision for music is http://selenium.qa.mtv2.mozilla.com:8080/view/B2G%20Perf/job/b2g.hamachi.mozilla-central.master.mozperftest/2813/