858986 - slow javascript performance on a typed array testcase with nested .call and so forth

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Leon Sorokin]

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

Comment 1

[Timvde]

You might want to put this bug in the Core product, JavaScript Engine component. Otherwise the chance is big that the JS devs miss it.

Comment 2

[Leon Sorokin]

thanks, switching to Core/JavaScript Engine

Comment 3

[Boris Zbarsky [:bzbarsky]]

Nothing jumping out at me from the profile other than some nested .call/.apply (not inlined?) and some js::ion::DoGetElemFallback under EnterBaseline...

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: zip of the files needed to reproduce

Comment 5

[Kannan Vijayan [:djvj]]

(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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Yeah, that probably explains why a bunch of this is running in baseline to start with...

Comment 7

[Leon Sorokin]

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.

Comment 8

[Hannes Verschore [:h4writer]]

.call performance should now be better since bug 884310 and bug 884298

Comment 9

[Boris Zbarsky [:bzbarsky]]

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.

Comment 10

[Kannan Vijayan [:djvj]]

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.