I've been working on a port of the Ogre3d game engine to js using Emscripten. When I load the port in Firefox, it starts to use 100% of CPU and it doesn't even show the slow script dialog. The profiler tells me that all of this time is being spent in ScriptAnalysis::AnalyzeSSA. Chrome can load this demo and run it in a matter of a few seconds. Please see the URL for the demo page (warning, large file, ~136MB).
Just a guess, but this might be caused by the same problem in bug 687127. Might be worth testing with the patch there.
The fix for that bug landed, and it doesn't help with this one, sadly. I also get a very very long stall of the browser, without the slow script dialog. It's so long I eventually gave up.
Created attachment 598966 [details] [diff] [review] patch (aa8ab7f39600) Make some efficiency improvements to the SSA analysis to avoid blowup when dealing with long scripts with lots of branching. Information for switch statements with lots of targets is consolidated, and tracking info for pending branches is restructured to avoid walking the same information over and over when lazily constructing phis at those branch targets. With this patch applied, I get an 11 second pause to do the initial parse, and a couple 1-2 second pauses for analyzing SSA info in some very large scripts on the page. Other than that things load OK. I'm not sure if there are more efficiency improvements to fix those 1-2 analysis times, but if not then we'll want to investigate keeping that information around longer (the SSA info is thrown away on GC and is recomputed afterwards).
(In reply to Brian Hackett (:bhackett) from comment #3) > With this patch applied, I get an 11 second pause to do the initial parse, > and a couple 1-2 second pauses for analyzing SSA info in some very large > scripts on the page. When you say '11 second pause to do the initial parse' do you literally mean the frontend or do you mean frontend + SSA analysis?
Just the frontend. I instrumented the code with timers, ran the page twice and got 11.9 seconds both times for the initial frontend::CompileScript.
Wow, that's enormous! How does Chrome compare?
Chrome takes about 20 seconds to load the page for me, so there's not really a huge difference here (though Chrome, of course, remains interactive, but that's a job for bug 718121).
Ok, so our parsing isn't inordinately slow. I guess for any real apps that want to use this the app cache may help out by using XDR instead of parsing.