Re: [v8-users] Optimizaing v8 memory usage

[Ben Noordhuis]

On Wed, Nov 15, 2017 at 7:30 AM,   wrote:
> Hi,
> I'm looking for ideas for optimizing multi thread - multi isolate platform.
> Especially on memory footprint.
>
> Each thread runs an isolate and one context, and runs same function in the
> script several times ( some time even 100 times).
> We've made calls to GC, but I'm still looking for more suggestions on this.

Pass a ResourceConstraints in the Isolate::CreateParams config object
to Isolate::New().

If that isn't the answer to your question, then please be more specific. =)

-- 
-- 
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.

[v8-users] Optimizaing v8 memory usage

[fkpkot]

Hi,
I'm looking for ideas for optimizing multi thread - multi isolate platform.
Especially on memory footprint.

Each thread runs an isolate and one context, and runs same function in the 
script several times ( some time even 100 times).
We've made calls to GC, but I'm still looking for more suggestions on this.



-- 
-- 
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.

Re: [v8-users] code cacheing between isoalte

[fkpkot]

Thanks! it worked. although i did had issues with the api returning const 
but the ScriptCompiler::source api requiring non-const cache.

On Monday, November 13, 2017 at 11:01:49 AM UTC+2, Ben Noordhuis wrote:
>
> On Mon, Nov 13, 2017 at 7:02 AM,   wrote: 
> > hi, 
> > i have multi thread program with thread per isolate and context which 
> each 
> > runs the same script. 
> > 
> > Since they all compile same script - I'd like to use the compiler to 
> create 
> > cache and distribute it between them. 
> > Currently i get a crash when I get to the step of actually running the 
> > script: 
> > 
> > Can I share code cache (example below) between isolates?  and script 
> > compilations? 
> > 
> > code example: 
> > 
> > 
> > v8::TryCatch try_catch(thread_component_->thread_isolate); 
> > v8::ScriptOrigin script_origin(v8::String::NewFromUtf8( 
> > thread_isolate, 
> > fileName)); 
> > 
> > const v8::Local raw_script(v8::String::NewFromUtf8( 
> > thread_isolate,  file_code)); 
> > 
> > v8::MaybeLocal unbound_script; 
> > 
> > v8::ScriptCompiler::Source* script_cache = 
> > script_cache_manager->GetScriptCache(fileName); 
> > if (script_cache == nullptr) { 
> > script_cache = new v8::ScriptCompiler::Sourceraw_script, 
> > script_origin); 
> > unbound_script = 
> v8::ScriptCompiler::CompileUnboundScript(isolate, 
> > script_cache, v8::ScriptCompiler::kProduceCodeCache); 
> > script_cache = script_cache_manager->AddScriptCache(fileName, 
> > script_cache); 
> > } else { 
> > unbound_script = 
> v8::ScriptCompiler::CompileUnboundScript(isolate, 
> > script_cache, v8::ScriptCompiler::kConsumeCodeCache); 
> > } 
> > 
> > v8::Local script = 
> > unbound_script.ToLocalChecked()->BindToCurrentContext(); 
> > 
> > 
> > if (script.IsEmpty() || try_catch.HasCaught()) { 
> > 
> > 
> thread_component_->thread_isolate->ThrowException(try_catch.Exception()); 
> > return; 
> > } 
> > 
> > v8::MaybeLocal result(script->Run( 
> > isolate_context)); 
> > 
> > if (result.IsEmpty() || try_catch.HasCaught()) { 
> > 
> > 
> thread_component_->thread_isolate->ThrowException(try_catch.Exception()); 
> > return; 
> > } 
> > 
> > are there any suggestions for other optimazations i can do accross 
> isolates? 
>
> You can share scripts across isolates.  Invoke CompileUnboundScript() 
> with the kProduceCodeCache flag and cache the result of 
> Source::GetCachedData() afterwards. 
>
> On the next run, pass the cached data to the Source constructor and 
> pass that along with the kConsumeCodeCache flag to 
> CompileUnboundScript(). 
>

-- 
-- 
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.

Re: [v8-users] BSON to v8::Object performance issue

[Jakob Kummerow]

There are a bunch of optimizations going into object literal handling, so
the two versions are not at all equivalent: the JS version is expected to
be much faster. To make them more comparable, you could model the same
control flow in JS, roughly:

var input = {
"_id": {
"$oid": "5a00bad8f759511811e030ba"
},
"attributes": ...
};
function process(o) {
var result = {};
for (var key of Object.keys(o)) {
var value = o[key];
if (typeof value === "Number") {
...
} else if ... {

} else if (typeof value === "object") {
result[key] = process(value);
}
return result;
}
var output;
for (var i = 0; i < 26400; i++) {
output = process(input);
}

I don't see anything obviously wrong with your code.

However, if there are any assumptions you can make, maybe you can optimize
it. For example: do all your objects have the same shape? If so, using a
constructor function and just filling in the values should be faster than
assembling them one property at a time.


On Tue, Nov 14, 2017 at 11:46 AM Jean-Marc Le Roux <
jeanmarc.ler...@gmail.com> wrote:

> Hello,
>
> I'm trying to create NodeJS bindings for libbson.
> One of the things I need is to be able to transform a bson_t document into
> a v8::Object.
> Loading, iterating on bson_t documents and matching them with
> MongoDB-style queries it very fast: 50ms to load from my HDD, iterate and
> filter 26000 bson_t documents.
> On the same machine, converting the same BSON documents into v8::Object is
> painfully slow.
> So I suspect I missed something.
>
> Here is my code:
>
> Local
> iterator_to_value(Isolate* isolate, const bson_iter_t* iter)
> {
> switch (bson_iter_type(iter))
> {
> case BSON_TYPE_INT32:
> return Number::New(isolate, bson_iter_int32(iter));
> break;
> case BSON_TYPE_INT64:
> return Number::New(isolate, bson_iter_int64(iter));
> break;
> case BSON_TYPE_DOUBLE:
> return Number::New(isolate, bson_iter_double(iter));
> break;
> case BSON_TYPE_DOCUMENT:
> {
> bson_iter_t sub_iter;
> bson_iter_recurse(iter, _iter);
>
> Local obj = Object::New(isolate);
> while (bson_iter_next(_iter))
> {
> const char* key = bson_iter_key(_iter);
>
> obj->Set(
> String::NewFromUtf8(isolate, key),
> iterator_to_value(isolate, _iter)
> );
> }
>
> return obj;
> }
> break;
> case BSON_TYPE_ARRAY:
> {
> bson_iter_t sub_iter;
> uint32_t length;
> const uint8_t* array_data;
>
> bson_iter_array(iter, , _data);
> bson_iter_recurse(iter, _iter);
>
> Local array = Array::New(isolate);
> int i = 0;
>
> while (bson_iter_next(_iter))
> {
> array->Set(i++, iterator_to_value(isolate, _iter));
> }
>
> return array;
> }
> break;
> case BSON_TYPE_OID:
> {
> const bson_oid_t* oid = bson_iter_oid(iter);
> char oid_buffer[25];
>
> bson_oid_to_string(oid, oid_buffer);
>
> return String::NewFromOneByte(isolate, (uint8_t*)oid_buffer);
> }
> break;
> case BSON_TYPE_UTF8:
> {
> uint32_t length;
> return String::NewFromUtf8(isolate, bson_iter_utf8(iter,
> ));
> }
> break;
> }
>
> return Null(isolate);
> }
>
> Local
> fill_object(Isolate* isolate, Local& obj, const bson_t* document)
> {
> bson_iter_t iter;
> if (bson_iter_init(, document))
> {
> while (bson_iter_next())
> {
> const char* key = bson_iter_key();
>
> obj->Set(
> String::NewFromUtf8(isolate, key),
> iterator_to_value(isolate, )
> );
> }
> }
>
> return obj;
> }
>
> As you can see, it's very straight forward.
> *Transforming 26400 bson_t into v_::Object takes 1.23s.*
>
> I tried doing what I believe to be the same code in pure JS with a
> representative sample Object :
>
> var array = [];
> for (var i = 0; i < 25000; ++i)
> {
> array.push({
> "_id": {
>   "$oid": "5a00bad8f759511811e030ba"
> },
> "attributes": [
>   {
> "key": "smartshape.scene.node.path|default",
> "value": "/scene/Lot444.scene",
> "type": "imported"
>   },
>   {
> "key": "max x",
> "value": 196.5773162841797,
> "type": "computed"
>   },
>   {
> "key": "max y",
> "value": 18.55002021789551,
> "type": "computed"
>   },
>   {
> "key": "max z",
> "value": 

[v8-users] BSON to v8::Object performance issue

[Jean-Marc Le Roux]

Hello,

I'm trying to create NodeJS bindings for libbson.
One of the things I need is to be able to transform a bson_t document into 
a v8::Object.
Loading, iterating on bson_t documents and matching them with MongoDB-style 
queries it very fast: 50ms to load from my HDD, iterate and filter 26000 
bson_t documents.
On the same machine, converting the same BSON documents into v8::Object is 
painfully slow.
So I suspect I missed something.

Here is my code:

Local
iterator_to_value(Isolate* isolate, const bson_iter_t* iter)
{
switch (bson_iter_type(iter))
{
case BSON_TYPE_INT32:
return Number::New(isolate, bson_iter_int32(iter));
break;
case BSON_TYPE_INT64:
return Number::New(isolate, bson_iter_int64(iter));
break;
case BSON_TYPE_DOUBLE:
return Number::New(isolate, bson_iter_double(iter));
break;
case BSON_TYPE_DOCUMENT:
{
bson_iter_t sub_iter;
bson_iter_recurse(iter, _iter);

Local obj = Object::New(isolate);
while (bson_iter_next(_iter))
{
const char* key = bson_iter_key(_iter);

obj->Set(
String::NewFromUtf8(isolate, key),
iterator_to_value(isolate, _iter)
);
}

return obj;
}
break;
case BSON_TYPE_ARRAY:
{
bson_iter_t sub_iter;
uint32_t length;
const uint8_t* array_data;

bson_iter_array(iter, , _data);
bson_iter_recurse(iter, _iter);

Local array = Array::New(isolate);
int i = 0;

while (bson_iter_next(_iter))
{
array->Set(i++, iterator_to_value(isolate, _iter));
}

return array;
}
break;
case BSON_TYPE_OID:
{
const bson_oid_t* oid = bson_iter_oid(iter);
char oid_buffer[25];

bson_oid_to_string(oid, oid_buffer);

return String::NewFromOneByte(isolate, (uint8_t*)oid_buffer);
}
break;
case BSON_TYPE_UTF8:
{
uint32_t length;
return String::NewFromUtf8(isolate, bson_iter_utf8(iter, 
));
}
break;
}

return Null(isolate);
}

Local
fill_object(Isolate* isolate, Local& obj, const bson_t* document)
{
bson_iter_t iter;
if (bson_iter_init(, document))
{
while (bson_iter_next())
{
const char* key = bson_iter_key();

obj->Set(
String::NewFromUtf8(isolate, key),
iterator_to_value(isolate, )
);
}
}

return obj;
}

As you can see, it's very straight forward.
*Transforming 26400 bson_t into v_::Object takes 1.23s.*

I tried doing what I believe to be the same code in pure JS with a 
representative sample Object :

var array = [];
for (var i = 0; i < 25000; ++i)
{
array.push({
"_id": {
  "$oid": "5a00bad8f759511811e030ba"
},
"attributes": [
  {
"key": "smartshape.scene.node.path|default",
"value": "/scene/Lot444.scene",
"type": "imported"
  },
  {
"key": "max x",
"value": 196.5773162841797,
"type": "computed"
  },
  {
"key": "max y",
"value": 18.55002021789551,
"type": "computed"
  },
  {
"key": "max z",
"value": 22.87815856933594,
"type": "computed"
  },
  {
"key": "min x",
"value": 149.9346771240234,
"type": "computed"
  },
  {
"key": "min y",
"value": 18.54999732971191,
"type": "computed"
  },
  {
"key": "min z",
"value": -23.35353088378906,
"type": "computed"
  },
  {
"key": "box radius",
"value": 23.32131958007814,
"type": "computed"
  },
  {
"key": "center x",
"value": 173.25599670410156,
"type": "computed"
  },
  {
"key": "center y",
"value": 18.55000877380371,
"type": "computed"
  },
  {
"key": "center z",
"value": -0.23768615722655895,
"type": "computed"
  },
  {
"key": "width",
"value": 46.64263916015628,
"type": "computed"
  },
  {
"key": "height",
"value": 2.2888183600855427e-05,
"type": "computed"
  },
  {
"key": "depth",
"value": 46.231689453125,
"type": "computed"
  },
  {
"key": "box volume",
"value": 0.04935534689932106,
"type": 

[v8-users] Re: [blink-dev] Re: Intent to ship: Unicode property escapes in regular expressions

['Mathias Bynens' via v8-users]

For future reference: this landed

in V8 v6.4.276 and should thus be available in Chrome 64.


On Thu, Nov 9, 2017 at 10:48 PM, Adam Klein  wrote:

> LGTM (for v8 signoff purposes).
>
> On Thu, Nov 9, 2017 at 1:38 PM, 'Mathias Bynens' via blink-dev <
> blink-...@chromium.org> wrote:
>
>> Note that since this is a V8/JS feature, this post is just an FYI to
>> blink-dev — no signoff from Blink API owners is required.
>>
>> On Thu, Nov 9, 2017 at 10:29 PM, Mathias Bynens 
>> wrote:
>>
>>> Contact emails
>>>
>>> yang...@chromium.org, math...@chromium.org
>>>
>>> Spec
>>>
>>> https://github.com/tc39/proposal-regexp-unicode-property-escapes (stage
>>> 3 proposal)
>>>
>>> Summary
>>>
>>> The Unicode Standard assigns various properties and property values to
>>> every symbol. For example, to get the set of symbols that are used
>>> exclusively in the Greek script, search the Unicode database for symbols
>>> whose Script property is set to Greek.
>>>
>>> Unicode property escapes are a new type of escape sequence available in
>>> regular expressions that have the u flag set. They enable querying the
>>> Unicode database for certain properties and values.
>>>
>>> E.g. /\p{Script=Greek}/u.test('π') === true
>>>
>>> Link to “Intent to Implement” blink-dev discussion
>>>
>>> There was none.
>>>
>>> Is this feature supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> Yes.
>>>
>>> Demo link
>>>
>>> None. The explainer in the proposal offers some examples.
>>>
>>> Interoperability and Compatibility Risk
>>>
>>> In regular expressions without the u flag, the pattern \p is an
>>> (unnecessary) escape sequence for p. Patterns of the form \p{Letter}
>>> might already be present in existing regular expressions without the u
>>> flag, and therefore we cannot assign new meaning to such patterns without
>>> breaking backwards compatibility.
>>>
>>> For this reason, ECMAScript 2015 made unnecessary escape sequences like
>>> \p and \P throw an exception when the u flag is set. This enables us to
>>> change the meaning of \p{…} and \P{…} in regular expressions with the u
>>> flag without breaking backwards compatibility.
>>>
>>>
>>>-
>>>
>>>Edge/Chakra: public support; tracking issue:
>>>https://github.com/Microsoft/ChakraCore/issues/2969
>>>
>>>-
>>>
>>>Firefox/SpiderMonkey: public support; tracking issue:
>>>https://bugzilla.mozilla.org/show_bug.cgi?id=1361876
>>>
>>>-
>>>
>>>Safari/JavaScriptCore: shipped in Safari Technical Preview 42;
>>>tracking issue: https://bugs.webkit.org/show_bug.cgi?id=172069
>>>-
>>>
>>>Web developers: positive signals
>>>
>>>
>>> Is this feature fully tested?
>>>
>>> Yes. In addition to V8’s own tests (v8/test/mjsunit/harmony/regex
>>> p-property-*.js), Test262 includes tests for this feature
>>> 
>>> .
>>>
>>> OWP launch tracking bug
>>>
>>> https://bugs.chromium.org/p/v8/issues/detail?id=4743
>>>
>>> Entry on the feature dashboard 
>>>
>>> https://www.chromestatus.com/features/6706900393525248
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To view this discussion on the web visit https://groups.google.com/a/ch
>> romium.org/d/msgid/blink-dev/CADizRgbnTY1wLi6ZrF4_w74-PyZSg
>> ZgUruJrP4Q6-O1i5t6aMg%40mail.gmail.com
>> 
>> .
>>
>

-- 
-- 
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.