The 07/13 nightly regressed the performance of Emscripten generated code by a huge amount (about 30 times slower). The regression range is http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=46804c31366b&tochange=6489be1890c0. I'm currently bisecting it to see what changeset is at fault.

Might be bug 765435 if you are dealing with >500MB JS heap.

(In reply to Gregor Wagner [:gwagner] from comment #1) > Might be bug 765435 if you are dealing with >500MB JS heap. That could very well be it. I'm half way through bisection so I don't wanna back out that single patch right now and ruin my bisection session, I'll update the bug as soon as I confirm this.

You could just set javascript.options.mem.gc_dynamic_heap_growth to false in about:config

(In reply to Gregor Wagner [:gwagner] from comment #3) > You could just set javascript.options.mem.gc_dynamic_heap_growth to false in > about:config That didn't help, and unfortunately hg bisect took me to a merge changeset: $ hg bis -gThe first bad revision is: changeset: 99101:6489be1890c0 parent: 99070:6a640ca09064 parent: 99100:1f4ad785cca8 user: Ryan VanderMeulen <ryanvm@gmail.com> date: Thu Jul 12 20:46:27 2012 -0400 summary: Merge the last PGO-green inbound changeset to m-c. Maybe I should try bisecting in git...

Mabye it's not me :) If it is GC related you can see it if you turn on javascript.options.mem.log and watch the Error Console for GC events.

I believe hg bisect should bisect through merges intelligently, if you start it early enough (from a shared ancestor of the merged branches) - should be the same as with git.

(In reply to comment #5) > Mabye it's not me :) > If it is GC related you can see it if you turn on javascript.options.mem.log > and watch the Error Console for GC events. What would I watch for? A lot of GCs happening?

(In reply to comment #6) > I believe hg bisect should bisect through merges intelligently, if you start it > early enough (from a shared ancestor of the merged branches) - should be the > same as with git. I've already started to bisect with git. Git should be able to handle this type of bisection fine, even if you don't use a common ancestor...

(In reply to Ehsan Akhgari [:ehsan] from comment #7) > (In reply to comment #5) > > Mabye it's not me :) > > If it is GC related you can see it if you turn on javascript.options.mem.log > > and watch the Error Console for GC events. > > What would I watch for? A lot of GCs happening? Yes. Maybe compare the number of GCs with a nightly that doesn't show the regression.

Why not bisect on inbound?

OK, found the offending changeset: http://hg.mozilla.org/mozilla-central/rev/17bc02a42a1a Alex, could you please take a look? (This only happens if the Gecko Profiler add-on is turned on.)

Just to be sane, the performance is normal if the profiler is turned off?

I ran this with the demo in bug 774438 and the fps was back up where it was without profiling enabled. Fun fact: the interpreter is a lot slower than the JIT.

Comment on attachment 642815 [details] [diff] [review] patch Schwoops nit: no { } around single-line then branch

Thanks Alex for the quick fix! :-)

If that bug went to aurora, we should get the patch on that branch as well.

Comment on attachment 642815 [details] [diff] [review] patch [Approval Request Comment] Bug caused by (feature/regressing bug #): 772078 User impact if declined: profiling turns of the jit entirely Testing completed (on m-c, etc.): m-c Risk to taking this patch (and alternatives if risky): very low: only exercised when profiling is on

(In reply to comment #18) > If that bug went to aurora, we should get the patch on that branch as well. Absolutely!

Comment on attachment 642815 [details] [diff] [review] patch low risk, tested fix, approving.