Open Bug 1412791 Opened 3 years ago Updated 3 years ago

7.31 - 7.46% Resident Memory (android-4-3-armv7-api16, android-api-16-gradle) regression on push babd400c828aee19ce9416296a1d32deaee3a49a (Sun Oct 29 2017)

Categories

(Firefox Build System :: General, defect)

Unspecified
Android
defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: igoldan, Unassigned)

References

Details

(Keywords: perf, regression)

We have detected an awsy regression from push:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?changeset=babd400c828aee19ce9416296a1d32deaee3a49a

As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

  7%  Resident Memory summary android-4-3-armv7-api16 opt      183,262,194.50 -> 196,930,786.67
  7%  Resident Memory summary android-api-16-gradle opt        183,318,105.92 -> 196,722,813.67


You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=10235

On the page above you can see an alert for each affected platform as well as a link to a graph showing the history of scores for this test. There is also a link to a treeherder page showing the jobs in a pushlog format.

To learn more about the regressing test(s), please see: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/AWSY
See Also: → 1412785
:froydnj This are the AWSY regressions for the same bug 1412785. The same things I stated in
https://bugzilla.mozilla.org/show_bug.cgi?id=1412785#c1
apply to this bug as well
Component: Untriaged → Build Config
Product: Firefox → Core
:froydnj Can we do some config tweaks to resolve the Resident Memory regressions?
Flags: needinfo?(nfroyd)
This regression makes no sense to me.  Why would changing the compiler have any effect on memory usage?

Eric, do you know if there are logs (or memory reports, or anything) saved for these tests that we could examine?
Flags: needinfo?(nfroyd) → needinfo?(erahm)
(In reply to Nathan Froyd [:froydnj] from comment #3)
> This regression makes no sense to me.  Why would changing the compiler have
> any effect on memory usage?
> 
> Eric, do you know if there are logs (or memory reports, or anything) saved
> for these tests that we could examine?

This is `test_awsy_lite.html` which is a browser chrome test [1]. Geoff added it, but looking at the code I don't think we're saving the actual reports. You could possibly modify the test to dump memory reports but I'm not sure how uploading those works in browser chrome world.

:glandium previously mentioned it might be an increase in the binary size. Might be worth comparing before and after on that.

[1] http://searchfox.org/mozilla-central/rev/ed212c79cfe86357e9a5740082b9364e7f6e526f/mobile/android/tests/browser/chrome/test_awsy_lite.html
Flags: needinfo?(erahm)
Have you managed to look over the AWSY test issue?
Flags: needinfo?(nfroyd)
Here's a delta of binary sizes (before and after):

> 119664      assets/armeabi-v7a/libfreebl3.so
> 132804      assets/armeabi-v7a/libfreebl3.so
> +13140
> 
> 24984       assets/armeabi-v7a/liblgpllibs.so
> 21752       assets/armeabi-v7a/liblgpllibs.so
> -3232
> 
> 624952      assets/armeabi-v7a/libnss3.so
> 704464      assets/armeabi-v7a/libnss3.so
> +79512
> 
> 186652      assets/armeabi-v7a/libnssckbi.so
> 188472      assets/armeabi-v7a/libnssckbi.so
>  +1820
> 
> 73172       assets/armeabi-v7a/libsoftokn3.so
> 80968       assets/armeabi-v7a/libsoftokn3.so
> +7796
> 
> 22708296    assets/armeabi-v7a/libxul.so
> 24956392    assets/armeabi-v7a/libxul.so
> +2248096
> 
>  920372     lib/armeabi-v7a/libmozglue.so
> 1264656     lib/armeabi-v7a/libmozglue.so
> +344284
> 
>  256872     lib/armeabi-v7a/libplugin-container-pie.so
>   38148     lib/armeabi-v7a/libplugin-container-pie.so
> -218724
> 
>  256764     lib/armeabi-v7a/libplugin-container.so
>   33944     lib/armeabi-v7a/libplugin-container.so
> -222820

That gives us a total delta of:

> Ignoring libplugin-container:  +2,691,416 bytes
> Including libplugin-container: +2,249,872 bytes

Which isn't 13 MB but in memory that's probably a larger change.
(In reply to Eric Rahm [:erahm] (please no mozreview requests) from comment #6)
> Here's a delta of binary sizes (before and after):
> 
> > 22708296    assets/armeabi-v7a/libxul.so
> > 24956392    assets/armeabi-v7a/libxul.so
> > +2248096

Hm, this is weird (mozglue also shows a dramatic increase in code size).  Measurements locally indicated that clang was producing smaller code than gcc.  Are we not elfhacking things appropriately?

(In reply to Ionuț Goldan [:igoldan], Performance Sheriffing from comment #5)
> Have you managed to look over the AWSY test issue?

I have not.  I don't think they'd show anything interesting.
Flags: needinfo?(nfroyd)
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.