1314154 - Figure out what to do with startup cache for cross-compiled builds

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Chris Cooper [:coop] (he/him)]

As :glandium notes in https://bugzilla.mozilla.org/show_bug.cgi?id=1183613#c35 our cross-compiled Mac builds will not have a prefilled startup cache.

We should either figure out how to do this, or disable the startup cache (possibly on all platforms).

How often does the startup cache change? Could we use a static, reusable profile like we've considered doing for PGO builds? Maybe a nightly/weekly "test" job to update the profile?

Comment 1

[Mike Hommey [:glandium]]

Startup cache changes when javascript files in the browser change. Before looking at what kind of awful hacks we can come up to keep it working, someone should look at the perf impact of not having it at all. I guess starting with talos results from a normal build with one with where https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/installer/packager.py#392-409 is removed would be a good start, assuming we're actually checking first runs on talos, but I wouldn't be surprised if we're not.

Comment 2

[Mike Hommey [:glandium]]

FWIW, just looking at the linux64 build of 49.0.2, removing the startup cache would strip ~4.5MB off omni.ja and browser/omni.ja (compressed)

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

Talos we do a first run to populate the profile so we don't measure that.  We do have sessionrestore tests that reset that profile.  There is a good chance we could detect any changes.

If there is a try push (ideally with/without), I can retrigger enough to get a higher confidence and give us a better idea of the impact.

Comment 4

[Mike Hommey [:glandium]]

With no change:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=6f64d1282b9efb5dc83293a4f60184c6b43cd034

Without startup cache:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=8a9d276fa902bbd779a17b355b33d22b69a63415

Comment 5

[Chris AtLee [:catlee]]

One option would be to first do the build from the linux environment without the startup cache. Then run the binaries on a native OSX host and record the information needed for the startup cache and upload those as test artifacts. Finally we do a kind of repack that takes the original package and the information collected from the test run and adds the startup cache information to the build.

Comment 6

[Joel Maher ( :jmaher ) (UTC -8)]

it looks like sessionrestore and ts_paint have small regressions:
https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=6f64d1282b9efb5dc83293a4f60184c6b43cd034&newProject=try&newRevision=8a9d276fa902bbd779a17b355b33d22b69a63415&framework=1

Comment 7

[Chris Cooper [:coop] (he/him)]

(In reply to Joel Maher ( :jmaher) from comment #6)
> it looks like sessionrestore and ts_paint have small regressions:
> https://treeherder.mozilla.org/perf.html#/
> compare?originalProject=try&originalRevision=6f64d1282b9efb5dc83293a4f60184c6
> b43cd034&newProject=try&newRevision=8a9d276fa902bbd779a17b355b33d22b69a63415&
> framework=1

From previous discussion with jmaher, this *almost* fits into the noise for those tests (2-3% regression). I'm support WONTFIXing this at that threshold.

Comment #5 could be done, but is an awful lot of work.

Comment 8

[Dustin J. Mitchell [:dustin] (he/him)]

Can we get a decision on this?  This could potentially put the OS X migration into conflict with the datacenter move.

Comment 9

[Chris AtLee [:catlee]]

If we're not going to have a startup cache on OSX, should we consider not including it on other platforms as well?

Comment 10

[Chris Cooper [:coop] (he/him)]

(In reply to Chris AtLee [:catlee] from comment #9)
> If we're not going to have a startup cache on OSX, should we consider not
> including it on other platforms as well?

You mean just landing glandium's patch from comment #4? Maybe. The perfherder results from comment #6 show a slightly larger delta on Windows. jmaher should weigh in, but we should file a new bug if we are going to disable it or pref it off.

Comment 11

[Joel Maher ( :jmaher ) (UTC -8)]

so those are small regressions and not seen on e10s- regarding perf, it wouldn't be unrealistic to accept this- we just need to make sure we are not doing silly things.