bug 958075 comment 7 has some ideas for speeding up the mochitest test_extra_inherit_initial.html (which currently takes over 300 seconds on B2G opt, and over 900 seconds on B2G debug). I'm spinning off this bug to cover those speedups.

This patch us only yield after processing 20 properties (instead of after every single property).

Comment on attachment 8358767 [details] [diff] [review] part 1: process properties in larger batches Are you sure this is safe? I saw some single properties take multiple seconds in the b2g test log you linked me to (e.g. "animation", which has tons of subproperties, with tons of values), and the default slow script dialog is after 10s...

Comment on attachment 8358768 [details] [diff] [review] part 2: turn off CSS error reporting for this test r=me, but how much does it help the b2g times?

(In reply to Boris Zbarsky [:bz] from comment #4) > r=me, but how much does it help the b2g times? Quite a lot -- see bug 958075 comment 9 & through 11. tl;dr: - batching (part 1 here) improved our time by 9% of the time in the first trial, by 36% in the second trial. - disabling error reporting (part 2 here) improved our time by 34% in the first trial, 30% in the second. - Both together saved ~42. (only did one trial of that) I'll take a closer look at batching to see if we might get close to triggering the slow script dialog. I'm surprised I didn't trigger it in my Try run, given your comment 3. Maybe the slow script dialog is disabled on B2G mochitests?

Hmm. I'd been hoping for more speedup, but maybe the emulator really is just that slow. :(

Comment on attachment 8358767 [details] [diff] [review] part 1: process properties in larger batches r=me assuming this works.

(In reply to Boris Zbarsky [:bz] from comment #6) > Hmm. I'd been hoping for more speedup, but maybe the emulator really is > just that slow. :( Yeah. Gregor said in IRC that it's emulating ARM on x86, and we haven't really invested in optimizing the emulator yet, so it's known to be much slower than everything else.

(In reply to Daniel Holbert [:dholbert] from comment #5) > I'll take a closer look at batching to see if we might get close to > triggering the slow script dialog. I'm surprised I didn't trigger it in my > Try run, given your comment 3. Maybe the slow script dialog is disabled on > B2G mochitests? Actually, from my testing, it looks like the slow script dialog is disabled altogether for mochitests. So I don't think we need batching at all. I'll post a new patch that just drops the batching. More details: I tried doing everything in one batch here (no yielding), and got no issues. Then, for good measure, I tried doing each property 3 times (to triple the test duration, so that we'd be significantly longer than 30 seconds on Desktop platforms), and I still got no issues. (aside from *Output exceeded 52428800 bytes, remaining output has been truncated, but that was after this test completed.) I suspect maybe the slow script dialog might have been a problem back when dbaron initially wrote this test in 2009, but it's apparently not a problem for mochitests now.

Try run with all the properties in one single batch: https://tbpl.mozilla.org/?tree=Try&rev=e5392f58be46 Shows no slow-script / timeout issues (with this test) on any platform. Posting updated version of patch #1 shortly.

Comment on attachment 8360179 [details] [diff] [review] part 1, v2: process all properties without yielding r=me

https://hg.mozilla.org/integration/mozilla-inbound/rev/036d25d0dbfa https://hg.mozilla.org/integration/mozilla-inbound/rev/e2f17cd4c211

https://hg.mozilla.org/mozilla-central/rev/036d25d0dbfa https://hg.mozilla.org/mozilla-central/rev/e2f17cd4c211