Open Bug 1141471 Opened 9 years ago Updated 2 years ago

Array.prototype.slice() needs to be optimized

Categories

(Core :: JavaScript Engine, enhancement)

x86_64
All
enhancement

Tracking

()

People

(Reporter: lapsap7+mz, Unassigned)

References

()

Details

Attachments

(1 file)

Everyone agrees that theoretically Array.prototype.slice() should be a better way to clone an array than doing a for-loop/while-loop to copy element by element.  However, according to this webpage on benchmark:
http://jsperf.com/new-array-vs-splice-vs-slice/76
slice() on my Firefox 35.0.1 is a LOT slower than while-loop.  More precisely,
slice: 434,633 ops/sec vs while: 1,889,386 ops/sec

Using the same benchmark test on IE 11 and Google Chrome ver 40 (on Win7 64-bit), slice is a lot FASTER!

I think slice method can be optimized in Firefox.  Memory block copy in native C++?
Hm, the while-loop is about 3x slower on Nightly than in 35 here and barely faster than the slice. That needs investigation..
Main problem for slice here is our old friend malloc, to allocate the dynamic slots. If I change the array so that it has 126 elements I get:

SM: 144 ms
d8: 178 ms

However, if I add one extra element, we no longer use nursery allocation and we get:

SM: 534 ms
d8: 180 ms

(In reply to 石庭豐 (Seak, Teng-Fong) from comment #0)
> I think slice method can be optimized in Firefox.  Memory block copy in
> native C++?

Well it's not that easy unfortunately. We need to fire post barriers for generational GC, need to track element type information etc.

Anyway, as I said above, the actual copy is not the problem here. Most of our time is spent allocating the new array. Your while-loop doesn't have that issue because it uses a single array instead of creating a new one each time.
(In reply to Jan de Mooij [:jandem] from comment #2)
> Well it's not that easy unfortunately. We need to fire post barriers for
> generational GC, need to track element type information etc.

Er nvm this part, we do use a memcpy in this case with some extra work for barriers.
OK, here are the benchmark with "77"

        | FF 36.0.1 | Chrome 41 |  IE 11
--------+-----------+-----------+---------
slice   | 666,730   | 3,820,876 | 703,837
concat  | 625,986   | 3,272,164 | 718,593
while:  | 526,221   |   644,009 | 150,677
slice(0)| 704,095   | 3,105,080 | 696,559

Result for while in FF is indeed a lot less than before.
WFM?
If I didn't make any mistake while testing this, I got the same results for Chrome and Nightly on the shell testcase and on jsperf (it's Back!!!).
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: