Open
Bug 1141471
Opened 9 years ago
Updated 2 years ago
Array.prototype.slice() needs to be optimized
Categories
(Core :: JavaScript Engine, enhancement)
Tracking
()
NEW
People
(Reporter: lapsap7+mz, Unassigned)
References
()
Details
Attachments
(1 file)
1.44 KB,
text/x-c
|
Details |
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++?
Reporter | ||
Updated•9 years ago
|
Comment 1•9 years ago
|
||
Hm, the while-loop is about 3x slower on Nightly than in 35 here and barely faster than the slice. That needs investigation..
Comment 2•9 years ago
|
||
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.
Comment 3•9 years ago
|
||
(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.
Comment 4•9 years ago
|
||
Comment 5•9 years ago
|
||
The "while loop" test is just totally broken in http://jsperf.com/new-array-vs-splice-vs-slice/76 Someone created http://jsperf.com/new-array-vs-splice-vs-slice/77 recently which has that fixed, fwiw.
Reporter | ||
Comment 6•9 years ago
|
||
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.
Comment 7•8 years ago
|
||
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!!!).
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•