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

NEW
Unassigned

Status

()

Core
JavaScript Engine
5 years ago
4 years ago

People

(Reporter: Leon Sorokin, Unassigned)

Tracking

Trunk
x86_64
Windows 8
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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

5 years ago
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.
(Reporter)

Comment 2

5 years ago
thanks, switching to Core/JavaScript Engine
Component: General → JavaScript Engine
Product: Firefox → Core
Nothing jumping out at me from the profile other than some nested .call/.apply (not inlined?) and some js::ion::DoGetElemFallback under EnterBaseline...
Summary: slow javascript performance → slow javascript performance on a typed array testcase with nested .call and so forth
Created attachment 734633 [details]
zip of the files needed to reproduce
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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...
(Reporter)

Comment 7

5 years ago
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.
Flags: needinfo?(kvijayan)
.call performance should now be better since bug 884310 and bug 884298
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.
Flags: needinfo?(kvijayan)
You need to log in before you can comment on or make changes to this bug.