hi @pmlopes
May I ask a question?
I am wondering which part make es4x so fast comparing to node.js because as you mentioned in the video that GraalJS run as fast or almost fast as v8.
Does the performance gain from replacing libuv or run on GlaarVM ?
Or it is because you seem to wrap the node.js api by java implementation?
I'm really curious about that.
I'm Paulo and I've used my 10+ years of software development experience writing, rewriting, banging my head against the wall, editing and re-editing high-performance web application to make Vert.x ...
There are a couple of things that make it faster. The usage of netty provides faster IO than libuv, then vertx implements a different eventloop that uses all computing resources and gives better handling of async tasks, finally graalvm (in contrast to V8) can optimize the full application (not just the js script) it optimizes netty, vertx and the js code (graaljs + es4x) so in the end the JIT gives an extra boost to everything and you get that performance. The cost isn't free, you will see that this has the side effect that only works as expected for long running processes (short cli apps won't benefit from this).
It's really interesting but a little bit confusing to read vert.x with es4x.
As a beginner, I am not really sure about the relation between es4x and vert.x.
As far as I known, vert.x is independent with GraalVM and not support ES6 feature.
But ES4X supports ES6(which is awesome of course) and have to run GraalVM as the compiler and the runtime.
Back to something I feel not quite sure,
ES4X seems to support vert.x syntax but also ES6 syntax. Take timer for example, in vert.x I have to use vertx.setPeriodic() and in ES6 use setInterval().
They both work in ES4X project.
But in the ES4X example, I don't see the showcase about this kind capacity.
This is my personal question about Vertx. I not really sure the multiple event loops mean in the documents.
Even though a Vertx instance maintains multiple event loops, any particular handler will never be executed concurrently, and in most cases (with the exception of worker verticles) will always be called using the exact same event loop.
especially this line any particular handler will never be executed concurrently. Does it mean even I create A,B,C 3 event loops, if A event loop is executing one handler, B/C have to stall until A finish execution ?
3.Would I gain a lot performance benefit if I use es4x-launcher to run my current project written in Express.js ?
I'm Paulo and I've used my 10+ years of software development experience writing, rewriting, banging my head against the wall, editing and re-editing high-performance web application to make Vert.x ...
ES4X is a new JavaScript runtime that is supposed to replace the official vertx js. The official vertx js is using nashorn so it only supports ES5.1, it's not high performance and has a development workflow based on java tools such as maven and not npm.
The goal is that with version 4 vertx will drop that js runtime and adopt ES4X.
This brings to the following question, ES4X is based on vertx, not libuv so express will not work out of the box but writing an API shim could be doable but it's not on my plans atm.
Finally regarding the multiple event loops, they never block each other, what is guaranteed is that if a request is started on event loop A then all handlers for that request are handled on event loop A to avoid context switching and improve performance.
hi @pmlopes
May I ask a question?
I am wondering which part make es4x so fast comparing to node.js because as you mentioned in the video that GraalJS run as fast or almost fast as v8.
Does the performance gain from replacing libuv or run on GlaarVM ?
Or it is because you seem to wrap the node.js api by java implementation?
I'm really curious about that.
Thanks :)
There are a couple of things that make it faster. The usage of netty provides faster IO than libuv, then vertx implements a different eventloop that uses all computing resources and gives better handling of async tasks, finally graalvm (in contrast to V8) can optimize the full application (not just the js script) it optimizes netty, vertx and the js code (graaljs + es4x) so in the end the JIT gives an extra boost to everything and you get that performance. The cost isn't free, you will see that this has the side effect that only works as expected for long running processes (short cli apps won't benefit from this).
hi Paulo, it's me again. :P
It's really interesting but a little bit confusing to read vert.x with es4x.
As a beginner, I am not really sure about the relation between es4x and vert.x.
As far as I known, vert.x is independent with GraalVM and not support ES6 feature.
But ES4X supports ES6(which is awesome of course) and have to run GraalVM as the compiler and the runtime.
Back to something I feel not quite sure,
vertx.setPeriodic()
and in ES6 usesetInterval()
. They both work in ES4X project. But in the ES4X example, I don't see the showcase about this kind capacity.especially this line
any particular handler will never be executed concurrently
. Does it mean even I create A,B,C 3 event loops, if A event loop is executing one handler, B/C have to stall until A finish execution ?3.Would I gain a lot performance benefit if I use
es4x-launcher
to run my current project written in Express.js ?Thanks for your answer and contribution.
Hi,
ES4X is a new JavaScript runtime that is supposed to replace the official vertx js. The official vertx js is using nashorn so it only supports ES5.1, it's not high performance and has a development workflow based on java tools such as maven and not npm.
The goal is that with version 4 vertx will drop that js runtime and adopt ES4X.
This brings to the following question, ES4X is based on vertx, not libuv so express will not work out of the box but writing an API shim could be doable but it's not on my plans atm.
Finally regarding the multiple event loops, they never block each other, what is guaranteed is that if a request is started on event loop A then all handlers for that request are handled on event loop A to avoid context switching and improve performance.
Thanks for your patient and explanation.
It solved my problem when I knew the ES4X is a JS runtime.
Really appreciate.