+++ This bug was initially created as a clone of Bug #704898 +++ Following is the original text of bug 704898, it still applies to XUL UI (not Native) because of bug 701833. Bug 701996 broke elfhack, and elfhack was disabled as a result. Bug 703305 fixed elfhack, so we should re-enable it. Especially considering this: 11-23 19:57:42.208 E/GeckoLibLoad( 9085): Loaded libs in 1268ms total, 742ms user, 183ms system, 13 faults 11-23 19:57:42.208 E/GeckoLibLoad( 9085): Spent 273ms on relocations, 3ms on constructors With elfhack, relocations time goes near 0, and constructors time stays under 30ms (iirc). It also makes the mount of data to uncompress smaller, which means faster decompression. A nightly with elfhack enabled, on the same device, loads libraries under 900ms.
Created attachment 597753 [details] [diff] [review] Re-enable elfhack on Fennec XUL
Comment on attachment 597753 [details] [diff] [review] Re-enable elfhack on Fennec XUL [Approval Request Comment] Elfhack was disabled because bug 701996 broke it, but elfhack was fixed in bug 703305, so it was re-enabled on native UI shortly after. However, it was left out on XUL UI. User impact if declined: Slower startup. Testing completed (on m-c, etc.): elfhack is in use on these branches on Native UI. Risk to taking this patch (and alternatives if risky): none.
Comment on attachment 597753 [details] [diff] [review] Re-enable elfhack on Fennec XUL [Triage Comment] Approved for mozilla-beta. Is this nominated for m-r approval because this build config won't be uplifted on the next merge day?
Comment on attachment 597753 [details] [diff] [review] Re-enable elfhack on Fennec XUL Erf, that was meant to be a nomination for aurora, not m-r.
http://hg.mozilla.org/releases/mozilla-aurora/rev/5da86f8addbb http://hg.mozilla.org/releases/mozilla-beta/rev/0e30f13e9012 Also landed on the COMM110_2012022204_RELBRANCH by mistake :( http://hg.mozilla.org/releases/mozilla-beta/rev/784d035cbc23