4 ms·

In V8, crossing the boundary between the public C++ API and "js land" is actually quite expensive. In most cases you will get more perf from writing your code i

by snek 8y ago

In V8, crossing the boundary between the public C++ API and "js land" is actually quite expensive. In most cases you will get more perf from writing your code in JS. This is why we write a lot of Node.js's core in JS instead of C++. Operations you see in the compiled output like `Local<Function>::Cast(global_3->Get(String::NewFromUtf8(isolate, "Boolean")));` are extraordinarily expensive, and should pretty much be avoided at all costs.

eatonphil 8y ago
Thanks for the info. jsc right now is little more than PoC and I don't have a ton of hope for competing with V8 for performance long term (except perhaps when type inference or hinting enter the story). The most immediate advantage I can think of for having a project like jsc long-term is for packaging/deployment. we use zeit's pkg tool at work today but a robust/mature Javascript-to-native compiler is much more compelling.
- mncharity 8y ago
  > competing with V8 The early python community went for C monoliths, but there was an alternative of python objects carrying C pointers. So python provides a form of api/plugin runtime dynamic linkage for smaller-grainsize C libraries. I don't know if anyone has explored that for javascript. If you've a problem domain of interest in need of almost-native speed (pointer call rather than static linkage) with 'compute-intensive runtime assemblages of C chunks' (eg, graphics or scientific), it might be a possibility. > [...limited subset of javascript...?] I don't quickly find the comment I intended to reply to, but fwiw, note that the ecmascript spec is written in sort-of pseudo-code English. Many years back I framed spec implementation as a semi-manual textural database cleanup and transformation exercise, and in a couple of days massaged spec into code. It helped that the target language had label gotos and permitted arbitrary identifiers, so the transformation was simple, and the resulting code looked like just like the spec. (Kind of ironic to see a comment elsewhere on this page dis'ing regexps.)

by snek 8y ago

eatonphil 8y ago

Thanks for the info. jsc right now is little more than PoC and I don't have a ton of hope for competing with V8 for performance long term (except perhaps when type inference or hinting enter the story). The most immediate advantage I can think of for having a project like jsc long-term is for packaging/deployment. we use zeit's pkg tool at work today but a robust/mature Javascript-to-native compiler is much more compelling.

mncharity 8y ago
> competing with V8 The early python community went for C monoliths, but there was an alternative of python objects carrying C pointers. So python provides a form of api/plugin runtime dynamic linkage for smaller-grainsize C libraries. I don't know if anyone has explored that for javascript. If you've a problem domain of interest in need of almost-native speed (pointer call rather than static linkage) with 'compute-intensive runtime assemblages of C chunks' (eg, graphics or scientific), it might be a possibility. > [...limited subset of javascript...?] I don't quickly find the comment I intended to reply to, but fwiw, note that the ecmascript spec is written in sort-of pseudo-code English. Many years back I framed spec implementation as a semi-manual textural database cleanup and transformation exercise, and in a couple of days massaged spec into code. It helped that the target language had label gotos and permitted arbitrary identifiers, so the transformation was simple, and the resulting code looked like just like the spec. (Kind of ironic to see a comment elsewhere on this page dis'ing regexps.)