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
for (var i = 0; i < arrayBinding.length; i++) {
array[i] = arrayBinding.get(i)
}
return array
}
// All set to go!
var array = getArray()
doSomething(array)
If you are dealing with large arrays, you might have to deal with the
slowness, since it'll kill your memory to release it, but if you're dealing
with an array with up to a thousand or so elements, you should be in the
clear. Don't try to outsmart the engine - there's a reason it executes JS
almost the speed of C++, the language it's written in.
On Friday, October 16, 2015 at 6:20:31 PM UTC-4, Dmitry Orlov wrote:
>
> Thanks Jacob!
>
> On 16 October 2015 at 13:56, Jakob Kummerow <jkum...@chromium.org
> <javascript:>> 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. Accessing things
>> via the C++ API ("array->Set(...)" in your example) isn't anywhere near as
>> optimized. The difference is most pronounced for tight hot loops, it will
>> be much smaller (to the point of being negligible) for code that runs only
>> once.
>>
> Is there any way to bulk-allocate a v8::Array in a cheap way, for example,
> from a C-array of v8::Handle<v8::Value>s?
>
>
>>
>> That said, if "Build Type: DEBUG" in your output means what I think it
>> means, then any performance measurement results are pretty much
>> meaningless. Try again in Release mode.
>>
> This message is reported because the Google benchmark library was build
> without NDEBUG directive:
>
> https://github.com/google/benchmark/blob/cf40a0f1172afc061e910eb5590f71e6ffdece66/src/console_reporter.cc#L43
> Apparently, that is the way its Makefile is written.
>
> My code is compiled wtih -O3:
> CXXFLAGS=-Wall -Werror -g -O3 -march=corei7 -mtune=corei7-avx -std=gnu++0x
> -pthread
>
> Is it possible that I inadvertently built V8 in debug mode? This is how I
> install it:
> $ export PATH=$PATH:/path/to/depot_tools
> $ fetch v8
> $ cd v8
> $ git fetch
> $ git checkout 4.2.77.21
> $ gclient sync
> $ make clean
> $ make -j8 native
>
>
>
>>
>> On Fri, Oct 16, 2015 at 8:57 PM, Dmitry Orlov <alep...@gmail.com
>> <javascript:>> wrote:
>>
>>> 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
>>> nanoseconds one would expect from a C-array based implementation.
>>> In contrast, javascript code using arrays runs blaze-fast, taking around
>>> 2ns for each assignment.
>>>
>>> I've benchmarked these code fragments separately, implementation is
>>> below:
>>>
>>> void allocate_v8_integer_array(benchmark::State& state) {
>>> v8::HandleScope scope(isolate);
>>> v8::Local<v8::Value> int_value = v8::Integer::New(isolate, 100);
>>> while (state.KeepRunning()) {
>>> const int n = state.range_x();
>>> v8::Local<v8::Array> array = v8::Array::New(isolate,
>>> state.range_x());
>>> for (int i = 0; i < n; ++i) {
>>> array->Set(i, int_value);
>>> }
>>> }
>>> }
>>>
>>> void allocate_v8_integer_array_in_javascript(benchmark::State& state) {
>>> v8::TryCatch try_catch(isolate);
>>> v8::HandleScope scope(isolate);
>>> v8::Local<v8::Script> script =
>>> v8::Script::Compile(v8::String::NewFromUtf8(isolate,
>>> "function run(n) {"
>>> " var x = Array(n);"
>>> " for (var i = 0; i < n; i++) {"
>>> " x[i] = i;"
>>> " }"
>>> "}"));
>>> script->Run();
>>> assert(!try_catch.HasCaught());
>>> v8::Local<v8::Function> run = v8::Local<v8::Function>::Cast(
>>>
>>> context.Get(isolate)->Global()->Get(v8::String::NewFromUtf8(isolate,
>>> "run")));
>>> v8::Local<v8::Value> arg = v8::Integer::New(isolate,
>>> state.range_x());
>>> while (state.KeepRunning()) {
>>> run->Call(context.Get(isolate)->Global(), 1, &arg);
>>> assert(!try_catch.HasCaught());
>>> }
>>> }
>>>
>>> Benchmark results:
>>> Run on (8 X 3399.98 MHz CPU s
>>> 2015-10-16 18:47:44
>>> Build Type: DEBUG
>>> Benchmark Time(ns) CPU(ns)
>>> Iterations
>>>
>>> ---------------------------------------------------------------------------------
>>> allocate_v8_integer_array/1 190 190
>>> 3688287
>>> allocate_v8_integer_array/10 1061 1061
>>> 659836
>>> allocate_v8_integer_array/100 9936 9930
>>> 70495
>>> allocate_v8_integer_array/1000 96517 96458
>>> 7259
>>> allocate_v8_integer_array/9.76562k 967739 967146
>>> 724
>>> allocate_v8_integer_array_in_javascript/10 487 486
>>> 3104447
>>> allocate_v8_integer_array_in_javascript/100 1075 1074
>>> 1000000
>>> allocate_v8_integer_array_in_javascript/1000 3576 3573
>>> 264306
>>> allocate_v8_integer_array_in_javascript/9.76562k 22218 22204
>>> 33641
>>>
>>> Note how allocate_v8_integer_array asymptotes at 100ns per array
>>> assignment, where allocate_v8_integer_array_in_javascript asymptotes at 2ns
>>> per assignment.
>>> I would expect v8::Array to be the internal array representation for the
>>> javascript too. Is that not the case? Why the performance difference is so
>>> high?
>>>
>>> Thank you very much!
>>> Dmitry.
>>>
>>> --
>>> --
>>> v8-users mailing list
>>> v8-u...@googlegroups.com <javascript:>
>>> 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 v8-users+u...@googlegroups.com <javascript:>.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> --
>> v8-users mailing list
>> v8-u...@googlegroups.com <javascript:>
>> http://groups.google.com/group/v8-users
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "v8-users" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/v8-users/_fuFjcsktzc/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> v8-users+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
--
v8-users mailing list
v8-users@googlegroups.com
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 v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
