Hi @ChromiumDev, previously code like `new ArrayBuffer(LARGE_NUMBER)` took several hundred milliseconds to execute. With todays Canary it doesn’t even take a single millisecond. How is that possible?
-
-
Replying to @chrisguttandin @ChromiumDev
What are you measuring exactly, and how? Either way, *summons
@hooraybuffer*1 reply 0 retweets 1 like -
We used a special allocator for ArrayBuffer memory which didn't support pre-initialized memory. Now it does. And it's way fast! We don't have to memset the uninitialized memory anymore --> https://bugs.chromium.org/p/chromium/issues/detail?id=864462 …
1 reply 0 retweets 2 likes -
Some time ago I noticed that it can (sometimes) take some time to allocate an ArrayBuffer (or TypedArray). To avoid any delay on the main thread I created https://github.com/chrisguttandin/async-array-buffer … . It can be used to allocate an ArrayBuffer in a worker. It then sends it back as a transferable.
1 reply 0 retweets 0 likes -
Replying to @chrisguttandin @hooraybuffer and
Thanks for the link
@hooraybuffer . Do I understand that correctly that v8 will now use pre-initialized memory? What happens if (for whatever crazy reason) there is no pre-initialized memory left to use?1 reply 0 retweets 0 likes -
v8 when embedded in Chromium uses the pre-initialized memory, yes. We get the zeroed pages from the OS, so it will just zero the page on demand (essentially as slow as memset) if there is no more pre-initialized memory left.
1 reply 0 retweets 0 likes -
It might be a stupid question, but is this likely to happen or is it almost impossible to run out of pre-initialized memory? I’m asking because I wonder if I should deprecate my async-array-buffer package or not.
1 reply 0 retweets 0 likes -
I think it will always be faster or the same speed without the workers now, for chromium. In Node.js, the allocator calls system calloc() directly so it depends on the system allocator, but I suspect that is also faster. If not, we should fix it there too, so it's fast by default
1 reply 0 retweets 0 likes -
Thanks a lot. I guess I have to come up with a clever way to detect if the worker-workaround (TM) is needed or not. Hopefully without doing any browser sniffing. At least Safari (I have not tested Edge) has still problems with allocating large ArrayBuffers.
2 replies 0 retweets 0 likes -
Replying to @chrisguttandin @hooraybuffer and
The idea is to free the garbage collection of the main thread from taking care of that ArrayBuffer and let the worker do it without causing jank on the main thread. I was never able to come up with a test which verifies that this is a good idea. I guess you know if it is or not.
1 reply 0 retweets 0 likes
It's probably not worth it - we already process ArrayBuffers in parallel during GC and then we put the backing store pointers onto a queue to be released on a background thread. For a few very large buffers, the cost is minimal. Millions of tiny buffers might be different.
-
-
Thanks a lot for explaining this to me.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.