1638763 - 0.36 - 0.48% installer size (osx-shippable) regression on push 9b8606a93c7591af9ebf57e6cbf2afb52f970ac5 (Fri May 15 2020)

Status: RESOLVED WONTFIX

(Firefox :: Sync, defect)

Description

[Alexandru Ionescu (needinfo me) [:alexandrui]]

Perfherder has detected a build_metrics performance regression from push 9b8606a93c7591af9ebf57e6cbf2afb52f970ac5. As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

0.48% installer size osx-shippable opt instrumented 116,040,060.83 -> 116,595,368.92
0.36% installer size osx-shippable opt nightly 83,181,379.71 -> 83,482,199.25

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests. Please follow our guide to handling regression bugs and let us know your plans within 3 business days, or the offending patch(es) will be backed out in accordance with our regression policy.

For more information on performance sheriffing please see our FAQ.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1631630

Comment 2

[Edouard Oger [:eoger]]

It's unfortunate but expected as we are moving the Sync/FxA internal parts to Rust. The installer size will go back down again once we remove the Javascript implementation.

Comment 3

[Nathan Froyd [:froydnj]]

(In reply to Edouard Oger [:eoger] from comment #2)

It's unfortunate but expected as we are moving the Sync/FxA internal parts to Rust. The installer size will go back down again once we remove the Javascript implementation.

Half a megabyte in the installer (!) is rather large, but the packages that push pulled in look pretty modest. Is there a lot of auto-generated/auto-derive'd code in there somewhere?

Comment 4

[Ryan Kelly [:rfkelly]]

Is there a lot of auto-generated/auto-derive'd code in there somewhere?

We do make fairly liberal use of Serde, e.g. in here where we use it for deserializing different types of HTTP response that we might get from the FxA server. Might be a contributing factor?

Comment 5

[Nathan Froyd [:froydnj]]

(In reply to Ryan Kelly [:rfkelly] from comment #4)

Is there a lot of auto-generated/auto-derive'd code in there somewhere?

We do make fairly liberal use of Serde, e.g. in here where we use it for deserializing different types of HTTP response that we might get from the FxA server. Might be a contributing factor?

I don't have a good mental model for how expensive a serde struct is, but it certainly seems plausible. What did the JS implementation do for this sort of thing? Just parsed it into JSON and called it a day?

Comment 6

[Ryan Kelly [:rfkelly]]

What did the JS implementation do for this sort of thing? Just parsed it into JSON and called it a day?

Yep.

Trying to guess at the source of the source of the size increase here probably isn't a good use of your or our time though; seems like it's worth us running a few local experiments to see if we can narrow down to a particular cause, it's the sort of thing that it will be good for us to have a handle on in general.

Comment 7

[Ryan Kelly [:rfkelly]]

seems like it's worth us running a few local experiments to see if we can narrow down to a particular cause

Investigating this over in the project repo here:

• https://github.com/mozilla/application-services/issues/3134