Looking at the big chunk of b2g-process work in http://people.mozilla.com/~bgirard/cleopatra/#report=3dda4851c74895beb767a168d733a95fae237a76 we see that the gaia system app is forcing a sync reflow under StatusBar.get height(). This reflow is costing ~25 samples (~30ms). We have to do this work eventually, but doing it synchronously here is bad for two reasons - it makes a mega event-loop iteration take even longer - it prevents gecko from using interruptible layout, which is better for responsiveness in general Here's a profile taken with the attached hacky patch applied http://people.mozilla.com/~bgirard/cleopatra/#report=742f3c620c41cd71083dd85ac60bdded7c5a1b34 While it's true that we've taken all these reflow samples, and pushed them somewhere else, we pushed them to a better place where they can be run more effectively. (The attached patch obviously isn't serious.)

I should note that the reflow in both cases is off the critical path; we've already initiated the load in the subprocess. But without the fix here, the reflow is more likely to cause the subprocess to block on the b2g process.

With this issue fixed we should more consistently hit the "positive effect" (*cough* luck) described in bug 835548 comment 10.

I have local patches for those Gaia stuff that slow us down. I will upload them asap.

Patch from Vivien.

Comment on attachment 710363 [details] [diff] [review] Cache the statusbar height Low-risk patch that keeps the b2g process more responsive during app startup.

Comment on attachment 710363 [details] [diff] [review] Cache the statusbar height That sounds more than reasonable.

Let's see if this get the blocking status as well.

v1-train: ba1c47f24e763469b9080cc87c412efb63a91c3e

Already landed on v1.0.1, no need to fix for v1.0.0.

Batch edit: Bugs fixed on b2g18 after 1/25 merge to v1.0 branch are fixed on v1.0.1 branch.