Thanks a lot for your yelling :) My general remark here is if you implement your own Buffer classes and not doing what the rest of the language does, in the long run you will not be able to benefit from all optimizations we will be doing to speed up ArrayBuffers and typed arrays.
I know that our d8 implementation of ArrayBuffers and friends has been pretty terrible w.r.t. allocation speed, but it is already improving and will improve further. On Wed, Nov 13, 2013 at 12:08 AM, Trevor Norris <[email protected]>wrote: > > > On Tuesday, November 12, 2013 12:08:28 AM UTC-8, Dmitry Lomov wrote: >> >> 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. >> > > Except they are at least twice as slow as our Node's internal Buffer > implementation for allocations over 1KB. I've been on the receiving end of > much debate about why Node doesn't transition to using ArrayBuffers and the > bottom line is always performance. > Is it still true in the latest releases (3.20 and up)? I am curious as to what is the bottleneck here. I remember you pointing out (in a different bug) that allocating weak handles is costly - non-externalized ArrayBuffers do not require any weak handles anymore, and we can think of ways to avoid weak handle allocation for some externalized array buffers as well. Ben mentioned zero-initialization: in my tests, zero-initialization cost was actually pretty small (maybe within 5%). Of course, we will never be able to ship something exposing uninitialized external memory to Javascript. > Other than the fact that instantiating an ArrayBuffer is slower, there's > the lost consideration of then needing to turn that into a Uint8Array > before it's usable. > You can allocate Uint8Array directly (I know it allocates an ArrayBuffer under the hood now - getting rid of that for some/most cases is one of my optimization goals). > What I feel you're considering a nuisance, being able to set external data > to any object, has been an excellent feature. With the release of Node > v0.12 there's a new API that'll allow users to roll out their own > Buffer-like classes. Making it easy to extend a constructed instance with > data and easily exposing a set of methods to work with the data. I myself > have been using this as a simplified way to create mathematical API's > around the object's instance directly. Instead of needing to pass around an > Type Array View. > > We use it extensively as an extremely light weight way of sharing state > between C++ and JS. Currently it's ridiculously slow to read Object > properties from a JS Object in C++, so a technique has been used where a > struct is wrapped around a set of data in C++ and that same data is > attached to an Object in JS. This way they can communicate as quickly as > possible. This has allowed significant performance gains. When the Function > is a singleton it's also useful to attach the memory directly to the > Function instead of an Object somewhere close by. > It feels like this scenario can be adequately captured by having an ArrayBuffer wrapping external data. It also aligns closely to the goals of typed objects proposal (formerly binary data: http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects), and again that is probably what V8 will be optimizing for. Looking through Buffer API (http://nodejs.org/api/buffer.html#buffer_buffer), I think that everything there can be implemented by subclassing Uint8Array (admittedly, we do not support subclassing of builtin objects yet! :)) Anyway, given how deep this external data feature had taken deep roots in node.js code, I agree that completely deprecating this API is premature. Here are the steps I would still like to do though: - Does node.js use any ExternalArrayType besides kExternalUnsignedByteArray? I'd love to reduce at least this part of the zoo. - I would dearly love to make sure node.js can switch to standard JS features instead of inventing your own. Can haz some benchmarks? :) I definitely do not want to force it down your throat though - I would like to get the perf to the point where the switch will be a perf win. Cheers, Dmitry -- -- 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.
