typearray perf seems to point out a bug |
|||
Issue descriptionChrome Version: 56.0.2924.76 (Official Build) (64-bit) OS: (e.g. Win7, OSX 10.9.5, etc...) What steps will reproduce the problem? (1) Run this test: https://jsperf.com/flipping-for-fun-and-profit/1 What is the expected result? The first result is faster than the second What happens instead? The second result is much slower than the first Run it in firefox and it comes out as expected Maybe there's something I don't understand but... I thought using `someTypedArray.copyWithin` is effectively supposed to be implemented as a call to `memcpy`. It seems to actually do that in Firefox (by perf) but not in Chrome. Similarly `someTypedArray.set(someOtherTypedArray)` should also boil down to just a call to `memcpy` but in both firefox and chrome it's clearly not based on perf Who can look into this? Ken, I added you to this because I don't know where it belongs and who deals with it. Originally I was using someTypedArray.set(someOtherTypedArray, ...) and things were going really slow. I thought maybe I didn't understand how set worked and why it might be slow so I tested only with `copyWithin`. It was still slow. So I checked firefox, it was fast. with copyWithin. So I added set back and now firefox was slow, not as slow as chrome but still slow. So I changed that test to use copyWithin in the main loop but there's still 2 large calls to `set` In anycase if you know where to bring this up. As it is it's almost like I'd be better of writing my own set in WebAssembly just to call it from JS which seems bad.
,
Feb 2 2017
Under
What happens instead?
It should read
The first result is much slower than the second
,
Feb 2 2017
I should also point out there's more weirdness. The example in comment #1 above shows Chrome's copyWithin is 2x slower than Firefox and set is about the same speed https://jsperf.com/typedarray-perf-issues/1 But if you run the example in the top https://jsperf.com/flipping-for-fun-and-profit/1 I added a few more cases The 2nd to the last case uses set. It's the code I original wrote that took me down this rabbit hole. In this case from is 706 times slow than firefox!!!! If set is only 2x slower and the code is using set out of 3 lines it should be at most 2x slower but it's not The last case just uses copyWithin. It doesn't function but it does use copyWithin to move as much data as would be moved if set was implemented using memcpy for compatible types. Again, based on the smaller test case this should be only 2x slower than firefox but it's nearly 3000 times slower than firefox. Even stranger it's 2.4x slower than the 2nd to the last case that uses set even though the smaller test claimed set is slower than copyWithin something is seriously fiahy
,
Feb 3 2017
Filed a bug on v8 if that's more appropriate https://bugs.chromium.org/p/v8/issues/detail?id=5925
,
Feb 4 2017
Thanks for reporting this Gregg. I added some more comments to the V8 bug you filed. That's the better place to report this performance issue so let me duplicate this into that one.
,
Aug 9 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by gman@chromium.org
, Feb 2 2017