Hi Jan, could you please have a look? There is no backout policy on these regressions, but a 3M+ increase in installer size is large. Fortunately Android (the platform where we care about installer size most) seems unaffected by this change, which is only visible on desktop. Note that MacOS X also increased, but I didn't include the numbers as its performance series is currently a bit wonky because of a bug in what we're submitting. -- We have detected a build metrics regression from push aad183efb09a7a93e189b07e2af363c136ecd1cd. As author of one of the patches included in that push, we need your help to address this regression. Regressions: 6% installer size summary linux32 opt 56325872.33 -> 59930258.58 5% installer size summary windowsxp opt 53456250.75 -> 56264872.4 5% installer size summary windows8-64 opt 57484694.88 -> 60294178.44 You can find links to graphs and comparison views for each of the above tests at: https://treeherder.mozilla.org/perf.html#/alerts?id=3352 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/Automated_Performance_Testing_and_Sheriffing/Build_Metrics

Interesting. The omni.ja file itself is actually a few MB smaller now, because we store more compressed sources instead of bytecode. Unfortunately, when *zipped*, the omni.ja file is actually a bit bigger than before. It makes sense because the already-compressed sources don't compress as well as the bytecode we used to store. The JS engine currently compresses script sources with the "max speed" flag. One option is to use "max compression" when we're compiling the startup cache. I'll experiment with this a bit.

On OS X, I get the following for the DMG file: before: 53.5 MB after: 57.0 MB max compression: 55.6 So tweaking the source compression wins about 1.4 MB, but we need 2.1 MB more. Two other options to investigate: (1) With lazy parsing, we should remeasure how effective the startup cache is. (2) Now that the XDR files contain the (compressed) JS source code, it seems omni.ja no longer needs the original *.jsm files. I wonder if we could remove all JSMs that we precompiled.

I backed this out. https://hg.mozilla.org/integration/mozilla-inbound/rev/b32a687a0a3ebd6db5806e69621563a0300fe6ce