Closed Bug 608742 Opened 9 years ago Closed 6 years ago

Change Fennec (Mobile) builds to use omnijar chrome format

Categories

(Release Engineering :: General, defect)

x86_64
Linux
defect
Not set

Tracking

(fennec-)

RESOLVED FIXED
Tracking Status
fennec - ---

People

(Reporter: mfinkle, Assigned: mfinkle)

References

Details

Attachments

(1 file, 1 obsolete file)

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
Attached patch patch (obsolete) — Splinter Review
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+
tracking-fennec: --- → 2.0b3+
Depends on: 535538
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)
Duplicate of this bug: 538021
Attachment #487527 - Flags: review?(blassey.bugs) → review+
Whiteboard: [fennec-checkin-postb2]
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
Whiteboard: [fennec-checkin-postb2][has-patch]
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?
tracking-fennec: 2.0- → 2.0next+
Is this patch landing again on mc ?
tracking-fennec: 2.0next+ → 6+
tracking-fennec: 6+ → 7+
tracking-fennec: 7+ → -
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
Flags: needinfo?(mark.finkle)
It's done
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(mark.finkle)
Resolution: --- → FIXED
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.