1382370 - Spread operator up to 3.5 times slower than apply()

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P3)

Description

[CoolCmd]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170719030206

Steps to reproduce:

see testcase: https://jsfiddle.net/CoolCmd/3b11kyda/
click the "run tests" button at the bottom right corner



Actual results:

apply x 55,472 ops/sec
spread x 16,328 ops/sec

this code
    String.fromCodePoint(...a)
is 3.5x slower than
    String.fromCodePoint.apply(this, a)


Expected results:

Chrome 58:
apply x 45,313 ops/sec
spread x 45,326 ops/sec

Edge 15:
apply x 58,834 ops/sec
spread x 31,114 ops/sec

Comment 1

[MegaScience]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170628075643

I have also noticed significantly worse performance of the Spread Operator.

I was looking for the least intensive method of concatenating arrays and found the answer in the first reference link. However, in testing with the Javascript performance test site in the second reference link, the Spread Operator performed noticeably worse than apply and concat. When I passed along the same test to a PC Chrome user, they reported the Spread Operator being the least intensive variant.

Running the test on Mobile versions of both browsers had identical results: Firefox's implementation is always slower. As per this report and its parent report, fixes are required for reliability and efficiency.

References:
- https://stackoverflow.com/a/5081471/5857393
- http://jsben.ch/rVji3

Comment 2

[Kagami Rosylight [:saschanaz] (they/them)]

It's now even 7x slower:

apply x 167,104 ops/sec ±2.45% (59 runs sampled)
spread x 23,645 ops/sec ±3.13% (60 runs sampled)

Comment 3

[Kagami Rosylight [:saschanaz] (they/them)]

Another testcase, this time for arrays: https://jsben.ch/B8mlf

Comment 4

[CoolCmd]

Testing Firefox 92 amd64 Windows 10:

apply x 361,964 ops/sec ±1.04% (64 runs sampled)
spread x 329,482 ops/sec ±0.99% (48 runs sampled)

Maybe -9% is acceptable, and this issue can be closed?

Comment 5

[Ted Campbell [:tcampbell]]

Agreed, let's close this.