New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 772154 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 27
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug

Blocked on:
issue v8:6896



Sign in to add a comment

Array.map seems to be about 7 times slower than it is if you replace the prototype with a javascript function

Reported by nicholas...@gmail.com, Oct 5 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce the problem:
1. Run a speed test using Array.map
2. Replace Array.prototype.map with a plain js function
3. Notice drastic speed improvement

What is the expected behavior?
I would expect Array.map to be faster than a loop with a push statement.

What went wrong?
Calling Array.map is significantly slower than expected.

If Array.map is replaced with a plain javascript function, then it is much faster.

Did this work before? No 

Chrome version: 61.0.3163.100  Channel: stable
OS Version: 6.3
Flash Version: 

This was uncovered when exploring why filling an array with a push statement in a loop was significantly faster than the map function.

https://jsperf.com/push-vs-map
 
Array speed test snippet.js
956 bytes View Download

Comment 1 by woxxom@gmail.com, Oct 5 2017

The native Array#map was always very slow in Chrome/V8 because AFAIK it's switching execution contexts between C++ and js.
I'm attaching test.html for more convenient test.

* Chrome 59 and older before r466685 updated V8 to version 6.0.65
	native: array size 10, repetitions 1000000 completed in 1260 ms
	custom: array size 10, repetitions 1000000 completed in 30 ms

	native: array size 100, repetitions 100000 completed in 1170 ms
	custom: array size 100, repetitions 100000 completed in 18 ms

	native: array size 1000, repetitions 10000 completed in 1155 ms
	custom: array size 1000, repetitions 10000 completed in 14 ms

	native: array size 10000, repetitions 1000 completed in 1152 ms
	custom: array size 10000, repetitions 1000 completed in 14 ms

	native: array size 100000, repetitions 100 completed in 1160 ms
	custom: array size 100000, repetitions 100 completed in 14 ms

* Chrome 60.0.3080.0 and newer, including Canary 63
	native: array size 10, repetitions 1000000 completed in 183 ms
	custom: array size 10, repetitions 1000000 completed in 31 ms

	native: array size 100, repetitions 100000 completed in 144 ms
	custom: array size 100, repetitions 100000 completed in 19 ms

	native: array size 1000, repetitions 10000 completed in 139 ms
	custom: array size 1000, repetitions 10000 completed in 16 ms

	native: array size 10000, repetitions 1000 completed in 139 ms
	custom: array size 10000, repetitions 1000 completed in 15 ms

	native: array size 100000, repetitions 100 completed in 1606 ms <<<<<<<<<<<<<<<<<<<<<<< WEIRD!
	custom: array size 100000, repetitions 100 completed in 37 ms

As you can see r466685 improved performance of native Array#map.
Previously it was 40-80 times slower, now it's "only" 6-40 times slower.
However, the large array case got slower.
It's also not clear why native implementation is slower at all.

P.S. in r466685 the related commit is 1eb0ef316103caf526f9ab80290b5ba313e232af
"[builtins] Improve performance of array.prototype.filter and map."
test.html
1.5 KB View Download

Comment 2 by woxxom@gmail.com, Oct 6 2017

In Firefox 58 the native Array#map is faster than both Chrome's native and FF's custom js:
	native: array size 10, repetitions 1000000 completed in 53 ms
	custom: array size 10, repetitions 1000000 completed in 47 ms

	native: array size 100, repetitions 100000 completed in 41 ms
	custom: array size 100, repetitions 100000 completed in 43 ms

	native: array size 1000, repetitions 10000 completed in 44 ms
	custom: array size 1000, repetitions 10000 completed in 83 ms

	native: array size 10000, repetitions 1000 completed in 41 ms
	custom: array size 10000, repetitions 1000 completed in 69 ms

	native: array size 100000, repetitions 100 completed in 55 ms
	custom: array size 100000, repetitions 100 completed in 85 ms

Cc: divya.pa...@techmahindra.com
Labels: M-63 Needs-Triage-M61 OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on reported version 61.0.3163.100, Latest Canary 63.0.3234.0 using Mac 10.12.6, Ubuntu 14.04 and Windows 10. 

This is a Non-Regression Issue as it is seen from M-50(50.0.2641.0), hence marking it as Untriaged.
Components: -Blink Blink>JavaScript
Components: -Blink>JavaScript Blink>JavaScript>Runtime Blink>JavaScript>Compiler
Labels: Performance
Status: Available (was: Untriaged)
Blockedon: v8:6896
Cc: bmeu...@chromium.org jarin@chromium.org danno@chromium.org
Owner: mvstan...@chromium.org
Status: Assigned (was: Available)
mvstanton@ is already working on improving the performance of Array#map and broadening the scope of the optimizations.
I was hoping to take a stab at it too and maybe make a pull request.  The codebase is very large, and it's taking quite a while to get familiar with it.
Labels: -Performance Performance-Browser
Status: Fixed (was: Assigned)
Clearing old bugs! The outlier of 1606 ms ("weird!") was fixed. A local run today:

$ out.gn/x64.release/d8 testhtml.js
native: array size 10, repetitions 1000000 completed in 37 ms
custom: array size 10, repetitions 1000000 completed in 27 ms

native: array size 100, repetitions 100000 completed in 23 ms
custom: array size 100, repetitions 100000 completed in 16 ms

native: array size 1000, repetitions 10000 completed in 20 ms
custom: array size 1000, repetitions 10000 completed in 13 ms

native: array size 10000, repetitions 1000 completed in 20 ms
custom: array size 10000, repetitions 1000 completed in 13 ms

native: array size 100000, repetitions 100 completed in 165 ms
custom: array size 100000, repetitions 100 completed in 121 ms


It was fixed by crrev.com/c/1301483 apparently - in Chrome 72.0.3597.0.

The fifth (last) set is still several times slower than the others, although 10x faster than the old "weird".
The first four sets are now 2.5x faster compared to Firefox 66, the fifth set is 2.5x slower.
Quite impressive, overall.

Sign in to add a comment