On Tue, Nov 12, 2013 at 10:25 AM, Dmitry Lomov <[email protected]> wrote: > > On Tue, Nov 12, 2013 at 10:15 AM, Ben Noordhuis <[email protected]> wrote: >> >> On Tue, Nov 12, 2013 at 9:08 AM, Dmitry Lomov <[email protected]> >> wrote: >> > As you probably know, over the course of the last several months, V8 >> > switched to an in-house implementations of ArrayBuffer, typed arrays and >> > DataView. These implementations feature faster allocation, better >> > garbage >> > collection performance and a potential to become even faster in the >> > future >> > with deep compiler optimizations - they are the finest available. >> > >> > Before these happy times however, V8 made do with a >> > v8::Object::SetIndexedPropertiesToExternalArrayData and a bunch of >> > associated APIs (also Get, Has and Length versions of the same), and >> > implementations of ArrayBuffer, typed arrays and other similar classes >> > were >> > provided by an embedder. However, embedder-provided typed arrays are >> > behind >> > us, and internal implementation of typed arrays and associated classes >> > will >> > be moving away from the mechanism underlying SetIndexedPropertiesTo* >> > API. >> > Supporting both in the long run is a burden on the code base (recall >> > that >> > SetIndexedPropertiesTo* API allows turning _any_ JS object into a kind >> > of >> > typed array). >> > >> > Therefore, over a course of the next few months, I plan to deprecate and >> > remove the following APIs: >> > void v8::Object::SetIndexedPropertiesToPixelData(uint8_t* data, int >> > length); >> > bool v8::Object::HasIndexedPropertiesInPixelData(); >> > uint8_t* v8::Object::GetIndexedPropertiesPixelData(); >> > int v8::Object::GetIndexedPropertiesPixelDataLength(); >> > >> > void v8::Object::SetIndexedPropertiesToExternalArrayData(void* data, >> > ExternalArrayType >> > array_type, >> > int number_of_elements); >> > bool v8::Object::HasIndexedPropertiesInExternalArrayData(); >> > void* v8::Object::GetIndexedPropertiesExternalArrayData(); >> > ExternalArrayType >> > v8::Object::GetIndexedPropertiesExternalArrayDataType(); >> > int v8::Object::GetIndexedPropertiesExternalArrayDataLength(); >> > >> > If you have objections, and know a use case which is not adequately >> > served >> > by V8's implementation of typed arrays &c, the time to yell is now. >> > >> > Cheers, >> > Dmitry >> >> That would break node.js completely. The Buffer class, which >> underpins pretty much everything in node.js, is built on top of >> v8::Object::SetIndexedPropertiesToExternalArrayData(). >> >> I don't see a reasonable way of switching to typed arrays. Buffers >> are not API-compatible with typed arrays and even if they were, the >> performance hit of zeroing memory on each allocation would probably >> not be acceptable. > > > You can always emulate non-zeroing-out memory behavior by using > v8::ArrayBuffer::New(void*, size_t) .
Right, but that doesn't help with objects that are new'ed in JS land. In node.js, you can call `new Buffer(31337)` (or just `Buffer(31337)`) and you get a Buffer object backed by that many bytes of uninitialized storage. > What are the API incompatibilities? They're numerous. Buffers have view rather than copy semantics. The constructor takes buffers, strings, arrays and probably other things I forgot. It has a ton of utility functions. The slice() method works differently. I can go on. In my opinion, it's unlikely that it can be implemented faithfully or efficiently by sub-classing, for example, Uint8Array. -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
