Closed Bug 608742 Opened 9 years ago Closed 6 years ago
Change Fennec (Mobile) builds to use omnijar chrome format
We should switch the current standard JAR chrome format to use omnijar. The resulting packages are slightly larger (the bz2 is ~755K larger), but the affect on Ts is worth it. Ts times improved by 755ms (average of 7 runs after throwing out the largest). The change needed is to add this line to the mozconfig: # chrome packaging ac_add_options --enable-chrome-format=omni
Does this rely on the packaging manifest stuff?
(In reply to comment #1) > Does this rely on the packaging manifest stuff? Nope
This patch updates the Maemo mobile nightlies, releases and try-server mozconfigs to use omnijar packaging. The patch only changes Maemo 5 GTK and QT builds.
Assignee: nobody → mark.finkle
Attachment #487364 - Flags: review?(aki)
Attachment #487364 - Flags: review?(aki) → review+
Michael Wu informed me that Firefox desktop sets the chrome file format in confvars.sh, which removes the burden from the mozconfig. I guess we can do it too. This means all builds, not just Maemo, will use omnijar - including developer builds. If anyone has issues with this, let me know.
Summary: Change Fennec (Mobile) builds to use omnijar chrome format on Maemo → Change Fennec (Mobile) builds to use omnijar chrome format
This patch also removes some unused variables from confvars.sh
Attachment #487527 - Flags: review?(blassey.bugs)
Attachment #487527 - Flags: review?(blassey.bugs) → review+
Whiteboard: [fennec-checkin-postb2] → [fennec-checkin-postb2][has-patch]
Comment on attachment 487364 [details] [diff] [review] patch We decided to use confvars.sh approach
Attachment #487364 - Attachment is obsolete: true
I had to back this out due to a large Ts regression. I have no idea how I could repeatably get large Ts improvements locally on my N900, but tinderbox has the opposite. http://hg.mozilla.org/mobile-browser/rev/7efccb14316c
We tried forcing a clobber, but the Ts regression remained. Another backout: http://hg.mozilla.org/mobile-browser/rev/b26d55b15854
This needs more study to see why we regress and we don't have a lot of time now. Pushing to post-4.0 The uncompressed omnijar support should help too.
tracking-fennec: 2.0b3+ → 2.0-
Hi Mark, it looks like there is a regression on mozilla-central that is effecting a performance regression. Your push to mobile-browser for omnijar also tested a bunch of mozilla-central changes at the same time. When the patches in the mozilla-central regression range were merged into tracemonkey the same performance hit was noticed. The regression range for mozilla-central is http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9912b2cfde1d&tochange=6edccbb39c1b Those changesets would have been pushed to TraceMonkey in http://hg.mozilla.org/tracemonkey/pushloghtml?changeset=a872a7883972 Not sure if you want to try again.
Did mwu's changes fix this?
Is this patch landing again on mc ?
Pretty sure this is already done.
Product: mozilla.org → Release Engineering
Found in triage. Last few comments look like this is all done... anything left to do here?
Component: Other → General Automation
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.