1427739 - Map/Reduce slow compared in Firefox Nightly vs Chrome

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect, P2)

Description

[Pascal Chevrel:pascalc (PTO until April 26)]

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

Comment 1

[Nicolas B. Pierron [:nbp]]

Ted, can you investigate if we ever JIT compile filter/reduce/forEach functions in these test cases?

Comment 2

[Ted Campbell [:tcampbell]]

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.

Comment 3

[Ted Campbell [:tcampbell]]

Throwing old bug to QF triage. The slowdown still exists but we have no current plans with it.

Comment 4

[Kannan Vijayan [:djvj]]

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.

Comment 5

[Matthew Gaudet (he/him) [:mgaudet]]

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.