blog/on-javascript-performance-01/

[utterances-bot]

Just(js): On Javascript Performance

A review of Javascript performance. Part 1 - Techempower Rankings.

https://just.billywhizz.io/blog/on-javascript-performance-01/

[MarshalOfficial]

please wait until the end of 20th round of TechEmpower, then use screenshots of the benchmark,
this is realtime status of the game: https://tfb-status.techempower.com/

[amoorahmat]

@MarshalOfficial Now let's go and check the live result, :)
it is on the top 2

[MarshalOfficial]

@amoorahmat just T tagged framework are important, I though, because they are full featured and rich frameworks

[billywhizz]

@MarshalOfficial yes it's a very bare bones effort at moment and is designed to see how fast we can make javascript go. i'm working on better libraries at the moment and will be doing a separate realistic/raw entry for techempower when i get time. i think i was clear in the article above about why you should take the results with a pinch of salt, but i don't think that makes them any less interesting.

[MarshalOfficial]

thanks @billywhizz
you have done great work, and I'm pretty hopeful about the future of just-js.
it was amazing in this round and will be.

[IvanTurgenev]

How does ram usage looks like?

[billywhizz]

How does ram usage looks like?

you can see more detail in the tool here. all those stats are available to download from techempower but they don't visualise them currently on their website.

[antonkatz]

Well done!

There's one answer that I was hoping to get from this post: "what is Just-js"?
If "Just" is a runtime on top of v8, how come it's so much faster than anything else written on top of v8?

These questions might sound very uneducated, feel free to school me :)

[billywhizz]

Hi @antonkatz. I thought the article did a pretty good job of explaining why this particular implementation is fast. I had to do an enormous amount of work over a number of weeks to benchmark against other frameworks locally, identify where bottlenecks were, try to understand what was causing them and then try to fix/work around them. Maybe not something you would do for a typical application.

In particular i think you are asking why it is faster than other JS implementations in the techempower benchmark. That's a difficult comparison to make as the next best performing JS framework is es4x which is based on vert.x and Java. The highest scoring node.js/v8 based entries are using various different databases so is hard to compare the overall score.

Let's focus on one benchmark for postgres, comparing just to node.js/express on the multi-query postgres test. We can see here just is approx 6x better than express-postgres.

Let's have a look in this tool to see what is going on in a bit more detail. We can see here express-postgres shows the following:

11k RPS, 84% CPU utlization of which 10% is system and 74% is user.

If we look at the same numbers for just we see

65k RPS, 15% CPU utlization, of which 4% is system and 11% is user.

So, in reality, the numbers are much worse. If we divide the RPS by the CPU utilized to see what max RPS would be under full utilization (in this case, the bottleneck is postgres) we see the following:

express/postgres = 11k / 0.84 = 13095 RPS @ 100% utilization
just = 65k / 0.15 = 433333k RPS @ 100% utilization

that is a factor of 33 better performance. just to repeat, the just solution here performs 33x better than the best node.js based solution.

digging into why this is the case in more detail would require a much longer answer but if you go look at the code in the express/postgres benchmark you can see there are layers and layers of dependencies before you even reach the node.js codebase. i will wager many of these dependencies are not heavily optimized and create a lot of unnecessary garbage.

firstly, express with url encoding, json middleware and routing built in: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/JavaScript/express/graphql-postgres-app.js

then, pg-promise with heavy use of promises: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/JavaScript/express/resolver-postgres.js

if we look at pg-promise we can see it has 24 dependencies. express has 52. if you want to go and figure out where all the bottlenecks are there, then i wish you very good luck 😀. it is one of the things that frustrates me most about the node.js/npm ecosystem - the default solution is just to import a metric shit-ton of external libraries, most of which are completely unnecessary for the task at hand.

i can understand this is probably fine when you are knocking together a PoC or when the cost of your web service is only a tiny fraction of your revenue, but when it is not and when your web service is a significant drain on your budget, then flushing 97% of the compute resources down the toilet seems kinda wasteful to me. 😅. this is where i see a niche for something like just(js).

hope that all makes sense.

[antonkatz]

Hi @billywhizz. Thank you for a comprehensive answer!

That does demystify part of my confusion.
My main confusion though is about what just is. I'm understanding that it's a thin wrapper around v8, correct?

A related question would be, why can't we just run JS right on top of v8? (see I'm totally uneducated!)

Again, thank you so much

[billywhizz]

@antonkatz I'll be putting some docs up soon and they will hopefully answer at least some of your questions. just is similar to node.js or deno in that it is v8 plus some wrappers around syscalls. in just's case, there is a deliberate decision not to wrap the syscall interfaces up in more complex abstractions which are likely going to be leaky and will require large amounts of ongoing maintenance over time (e.g. node.js streams). the linux/posix/systemV api's are quite nice and have been standards for a long time. i'd prefer to learn and work with those than some framework that likely won't exist in 5 or 10 years time. one nice feature of just is that pretty much any api call you see there you can just use the builtin linux man command to understand what it is doing.

i would argue that taking a little more time to write and understand this is going to be much more beneficial in the long run and will make finding and fixing bugs much easier than something like this.

[abdulghani]

this is very exciting.
interested to see production usage for this runtime.
it's going to be big.

[foswmine]

Great Work! Are just-js and mongodb a bad combination?

[schinraw]

It scored better because others were not using similar techniques or caching for single query like you did and similar