Closed Bug 1314154 Opened 3 years ago Closed 3 years ago

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

Categories

(Firefox Build System :: General, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: coop, Unassigned)

Details

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?
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.
Flags: needinfo?(jmaher)
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)
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.
Flags: needinfo?(jmaher)
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.
(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.
Can we get a decision on this?  This could potentially put the OS X migration into conflict with the datacenter move.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
If we're not going to have a startup cache on OSX, should we consider not including it on other platforms as well?
(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.
Flags: needinfo?(jmaher)
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.
Flags: needinfo?(jmaher)
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.