Some of my image analysis functions run much more slowly in FF nightly than Chromium nightly. Unfortunately, I don't have a greatly reduced test case but I do have a demonstration of the issue. Steps to reproduce: 1. Open http://o-0.me/ff-scan-slow/ in Chromium and Firefox 2. Look in console at the elapsed times for each output. 3. The first number is total time since start, second is time since prior console output. The .scanXY() method in Chromium achieves 30ms while Firefox is at 125ms on my laptop. This is a huge difference which I cannot explain. This algorithm does a full scan of an internal typed array that results from converting imageData to grayscale. For quick source browsing, i have open sourced pXY.js at https://github.com/leeoniya/pXY.js My completely random guess is that maybe it's the overhead of doing "new" on each pixel iteration, https://github.com/leeoniya/pXY.js/blob/master/src/pXY.js#L464 but Chrome somehow optimizes this very well. thanks! Leon
Nothing jumping out at me from the profile other than some nested .call/.apply (not inlined?) and some js::ion::DoGetElemFallback under EnterBaseline...
(In reply to Boris Zbarsky (:bz) from comment #3) > Nothing jumping out at me from the profile other than some nested > .call/.apply (not inlined?) and some js::ion::DoGetElemFallback under > EnterBaseline... I'm also noticing a bunch of |splice.call(arguments)| showing up here for arguments => array conversion, which we identified as a problem before because Ion doesn't handle it.
Yeah, that probably explains why a bunch of this is running in baseline to start with...
is there a perf bug open for this? i'd be interested in progress here since i have a lot of app code likely suffering from this on a much larger scale.
We do better than Firefox 21, say... I see scanXY take about 180ms for scanXY and nightly takes about 80ms. Chrome dev takes 17ms on the same hardware. A profile of current nightly is ... odd. For example, doing the scanXY call a bunch of times does NOT take noticeably more time than a single call.
I took a look at the current profile of this. The biggest thing I found (on MacOSX 64-bit) was that we're spending 25% of our time in DoGetPropFallback.