On Mon, Oct 19, 2015 at 10:24 PM, Dmitry Orlov wrote:
> However, in the real code, I have to pass large arrays of v8::Objects, not
> integers. It is possible to create an ArrayBuffer-backed array of object
> handles?
No, but you can pass a large number of arguments to JS
On Mon, Oct 19, 2015 at 10:24 PM, Dmitry Orlov wrote:
>
> On 18 October 2015 at 03:51, Jakob Kummerow
> wrote:
>
>> The fastest way to exchange large amounts of data between C++ and JS is
>> probably an externalized
>>
On 18 October 2015 at 03:51, Jakob Kummerow wrote:
> On Sat, Oct 17, 2015 at 12:20 AM, Dmitry Orlov
> wrote:
>
>> Thanks Jacob!
>>
>> On 16 October 2015 at 13:56, Jakob Kummerow
>> wrote:
>>
>>> It's not about what the
On Sat, Oct 17, 2015 at 12:20 AM, Dmitry Orlov wrote:
> Thanks Jacob!
>
> On 16 October 2015 at 13:56, Jakob Kummerow
> wrote:
>
>> It's not about what the "internal array representation" is, it's about
>> how the array is accessed. V8 employs all
Maybe do the array allocation and initialization from the JS side? This
will likely be extremely cheap to do, and almost as fast as simply
iterating the array.
function getArray() {
var arrayBinding = getNativeArrayBinding()
var array = []
// arrayBinding.length is a static property
It's not about what the "internal array representation" is, it's about how
the array is accessed. V8 employs all sorts of smarts to make JavaScript
execution very fast, because that's its job. Accessing things via the C++
API ("array->Set(...)" in your example) isn't anywhere near as optimized.
Thanks Jacob!
On 16 October 2015 at 13:56, Jakob Kummerow wrote:
> It's not about what the "internal array representation" is, it's about how
> the array is accessed. V8 employs all sorts of smarts to make JavaScript
> execution very fast, because that's its job.
Hello everyone,
I've noticed peculiar performance characteristics of V8 objects when
benchmarking my V8-embedding application. In particular, v8::Array is
incredibly expensive - each Set(index, value) operation on an array
consistently takes 100ns on a 3.4Ghz Xeon, instead of single digit