Closed Bug 1427739 Opened 7 years ago Closed 8 months ago

Map/Reduce slow compared in Firefox Nightly vs Chrome

Categories

(Core :: JavaScript Engine, defect, P2)

defect

Tracking

()

RESOLVED INCOMPLETE
Performance Impact medium
Tracking Status
firefox59 --- fix-optional

People

(Reporter: pascalc, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: nightly-community, perf)

Bug reported via Twitter:

"are ES6 maps slow right now? Operations seem to be much much slower than Chrome"
https://twitter.com/joshunger/status/947153710915784705

Josh provided a testcase: https://jsperf.com/reduce-vs-es6-map/

I can confirm on my machine on Nightly that on this testcase we are significantly slower than Chrome Dev:

Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0 ID:20180103100101
Map: 331 ops/s
Reduce: 147 ops/s

Chrome Dev Version 65.0.3298.3
Map: 401 ops/s
Reduce: 721 ops/s
Blocks: es6perf
Ted, can you investigate if we ever JIT compile filter/reduce/forEach functions in these test cases?
Flags: needinfo?(tcampbell)
Priority: -- → P2
Profile: https://perfht.ml/2nSufea

I'm not seeing Ion aborts. There are a lot of VMCalls. For the map case, we spend 30% of runtime in GC.
Throwing old bug to QF triage. The slowdown still exists but we have no current plans with it.
Flags: needinfo?(tcampbell)
Whiteboard: [qf]
Talked this over with tcampbell.  There is an interesting perf problem here, but it's not "map" vs. "reduce".  First, this is not a "map" vs. "reduce" problem in the first place.  The two tests being compared are:  reduce-into-object-literal vs. forEach-into-map-object.

The interesting thing here is the drastic slowdown of our reduce case vs the chrome reduce case, and the fact that we're spending massive amounts of time GC with the reduce case.

This suggests that an allocation is happening, but there's no place where an allocation should be happening - looking through the implementation of Reduce.  This suggests that the allocation occurring relates to the empty array literal inside the conditional in the reduce test case.

This may be an indication that Ion is hoisting an allocation where it shouldn't be (out of the conditional), and this performing eager allocations of arrays that will never be used.
Whiteboard: [qf] → [qf:p2:f64]
Whiteboard: [qf:p2:f64] → [qf:p2]
Performance Impact: --- → P2
Whiteboard: [qf:p2]
Severity: normal → S3

Unfortunately the test case has been lost to the sands of time, rendering this bug unactionable, and our performance efforts are currently focused elsewhere.

If this test case can be recovered, we could re-check the current state of the world and re-open.

Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.