Closed Bug 1314154 Opened 3 years ago Closed 3 years ago
Figure out what to do with startup cache for cross-compiled builds
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?
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.
With no change: https://treeherder.mozilla.org/#/jobs?repo=try&revision=6f64d1282b9efb5dc83293a4f60184c6b43cd034 Without startup cache: https://treeherder.mozilla.org/#/jobs?repo=try&revision=8a9d276fa902bbd779a17b355b33d22b69a63415
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.
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
(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.
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.
You need to log in before you can comment on or make changes to this bug.