Open
Bug 961977
Opened 10 years ago
Updated 4 months ago
IonMonkey: Consider Inlining Array.prototype.slice
Categories
(Core :: JavaScript Engine: JIT, defect, P3)
Tracking
()
NEW
People
(Reporter: isk, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: perf)
Attachments
(1 file)
223 bytes,
text/javascript
|
Details |
I'm attaching a shell test case. d8: 631ms SM: 2145ms SM is slower than d8. I think this is because Array#slice is not inlined.
Reporter | ||
Updated•10 years ago
|
Status: NEW → ASSIGNED
![]() |
||
Comment 1•10 years ago
|
||
Do you think that based on profiling, or something else?
Comment 2•10 years ago
|
||
Just wondering, what are the results if you replace arr.slice() by res.slice(), and do res = arr.slice() before the loop?
Reporter | ||
Comment 3•10 years ago
|
||
(In reply to Boris Zbarsky [:bz] from comment #1) > Do you think that based on profiling, or something else? Sorry I don't have exactly basis. I think inlining Array#slice can be fast because It is similar to MStringSplit. But I don't have any profiling which indicate the cause is it.
Reporter | ||
Comment 4•10 years ago
|
||
(In reply to Nicolas B. Pierron [:nbp] from comment #2) > Just wondering, what are the results if you replace arr.slice() by > res.slice(), and do res = arr.slice() before the loop? I measured it. The both result is the same.
Comment 5•7 years ago
|
||
SM: 900ms node: 490ms
Comment 6•7 years ago
|
||
don't forget the ability to do Array==Array.slice()
Updated•1 year ago
|
Severity: normal → S3
Comment 7•4 months ago
|
||
Nightly: https://share.firefox.dev/3QH7zN3 (335ms)
Chrome: https://share.firefox.dev/3OFPKLN (110ms)
You need to log in
before you can comment on or make changes to this bug.
Description
•