Issue 6934 in v8: ArrayBuffer.slice is slow

[spectral… via monorail]

Status: Untriaged
Owner: ----

New issue 6934 by spectral...@gmail.com: ArrayBuffer.slice is slow
https://bugs.chromium.org/p/v8/issues/detail?id=6934

ArrayBuffer.slice is incredibly slow.
It should, logically speaking, be faster than any alternative of copying a part of an ArrayBuffer.
However, not only is it slower than basically any other way for small sized copies, it's also slower than using a TypedArray.set at bigger copies.
Logically speaking these results shouldn't be possible.
I assume that what's going on is that some of the supposedly native calls are inlined into JS and don't need to cross the boundry between JS and native, but if that's the case, why isn't the same done for ArrayBuffer.slice?

Here's a test case where I show 5 different ways of coyping parts of an ArrayBuffer into a Float32Array of size 3, 10, 100, and 1000.
https://jsperf.com/typecast-vs-manual-slice

Note that this type of data copying is inherently required for arbitrarily sized and typed data, due to the typed arrays boundary check. E.g. can't make a Float32Array at an offset not divisible by 4.

I will note that the same exact behavior is seen in Firefox, so I am really interested if the lack of optimization is something to do with the spec.



--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

[spectral… via monorail]

Comment #1 on issue 6934 by spectral...@gmail.com: ArrayBuffer.slice is slow
https://bugs.chromium.org/p/v8/issues/detail?id=6934#c1

Excuse me, I had a logical error in the TypedArray.set test.
Fixed, it is still slightly faster for 1000 floats than an ArrayBuffer.slice on Chrome, but slower on Firefox.
At a larger size ArrayBuffer.slice will certainly be faster.

I am mostly interested why I can't use ArrayBuffer.slice for any size expecting it to be the fastest solution though.

[habl… via monorail]

Updates:
Components: Runtime
Labels: Priority-3
Owner: bmeu...@chromium.org
Status: Assigned

Comment #2 on issue 6934 by hab...@chromium.org: ArrayBuffer.slice is slow
https://bugs.chromium.org/p/v8/issues/detail?id=6934#c2

bmeurer@ could you please answer #1?

[bmeu… via monorail]

Updates:
Cc: bmeu...@chromium.org yan...@chromium.org
Labels: Performance HW-All OS-All
Owner: peterm...@chromium.org

Comment #3 on issue 6934 by bmeu...@chromium.org: ArrayBuffer.slice is slow
https://bugs.chromium.org/p/v8/issues/detail?id=6934#c3

ArrayBuffer#slice is a rather naive C++ builtin. Maybe there's something to gain here. petermarshall@ can you take a look?

[petermar… via monorail]

Comment #4 on issue 6934 by peterm...@chromium.org: ArrayBuffer.slice is slow
https://bugs.chromium.org/p/v8/issues/detail?id=6934#c4

I'll take a look

[spectral… via monorail]

Comment #5 on issue 6934 by spectral...@gmail.com: ArrayBuffer.slice is slow
https://bugs.chromium.org/p/v8/issues/detail?id=6934#c5

After thinking further, it might not really be possible.

Essentially it's the same problem as I have - an optimization will have to check at what size it becomes faster to move to C++, which is not practical because this will change for every computer, browser version, etc.

That being said, I know nothing about how JS compilers work.

Another weird quirk with the test above is that my own typecasting function is immensely faster for small sizes than a simple loop that copies bytes, while mine does a lot more work.
I can't explain that one.

[petermar… via monorail]

Comment #6 on issue 6934 by peterm...@chromium.org: ArrayBuffer.slice is slow
https://bugs.chromium.org/p/v8/issues/detail?id=6934#c6

The reason your typecasting function is faster is because of a weird quirk of our typed array representation. When creating a typed array by length, as you do in readFloat32ArrayTypecast, a size <= 64 bytes uses a special 'on-heap' representation of typed arrays. You can see that there is a performance cliff between readFloat32ArrayTypecast(16) and (17). 17 causes a 68 byte array to be created, which goes to a slower path and causes extra garbage collection overhead.

The slice builtin won't ever use this representation though, even if the size is small enough.

Some changes that optimize slice have also just landed in V8 - https://chromium-review.googlesource.com/c/v8/v8/+/859397. That CL hasn't landed in canary yet but should be there in a few days, so you could try it out for your use-case.

[peter… via monorail]

Updates:
Status: Fixed

Comment #7 on issue 6934 by peterm...@chromium.org: ArrayBuffer.slice is slow
https://bugs.chromium.org/p/v8/issues/detail?id=6934#c7

A lot of changes landed to slice so I think this is fixed