Last Comment Bug 725920 - Firefox extremely slow when loading my Ogre3d port
: Firefox extremely slow when loading my Ogre3d port
Status: RESOLVED FIXED
: perf
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: x86_64 Linux
: -- normal (vote)
: mozilla13
Assigned To: Brian Hackett (:bhackett)
:
Mentors:
http://people.mozilla.org/~eakhgari/d...
Depends on: 730888
Blocks: 644244
  Show dependency treegraph
 
Reported: 2012-02-09 20:01 PST by :Ehsan Akhgari
Modified: 2012-02-29 16:14 PST (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (aa8ab7f39600) (27.42 KB, patch)
2012-02-20 14:40 PST, Brian Hackett (:bhackett)
dvander: review+
Details | Diff | Splinter Review

Description :Ehsan Akhgari 2012-02-09 20:01:00 PST
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).
Comment 1 Alon Zakai (:azakai) 2012-02-09 20:07:39 PST
Just a guess, but this might be caused by the same problem in bug 687127. Might be worth testing with the patch there.
Comment 2 Alon Zakai (:azakai) 2012-02-14 09:18:47 PST
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.
Comment 3 Brian Hackett (:bhackett) 2012-02-20 14:40:25 PST
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).
Comment 4 Luke Wagner [:luke] 2012-02-20 15:04:47 PST
(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?
Comment 5 Brian Hackett (:bhackett) 2012-02-20 15:15:34 PST
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.
Comment 6 Luke Wagner [:luke] 2012-02-20 15:20:37 PST
Wow, that's enormous!  How does Chrome compare?
Comment 7 Brian Hackett (:bhackett) 2012-02-20 15:54:13 PST
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).
Comment 8 Luke Wagner [:luke] 2012-02-21 08:58:50 PST
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.
Comment 9 Brian Hackett (:bhackett) 2012-02-23 13:02:28 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/8ab9fea628bd
Comment 10 Marco Bonardo [::mak] 2012-02-24 02:31:19 PST
https://hg.mozilla.org/mozilla-central/rev/8ab9fea628bd

Note You need to log in before you can comment on or make changes to this bug.