51–60 of 69 posts
Earlier quoted context omitted.
Ofcourse; Deno is V8-based, which is a lot more full-featured than quickjs. Perhaps this is a more informative benchmark: https://bellard.org/quickjs/bench.html
Wow,, this is seriously bad. Calling this fast is very misleading. QuickJS is about 0.5x as fast as V8 without JIT (and like 20x slower than V8+JIT).
Earlier quoted context omitted.
Please explain.
Not all unicodes are equal for a screen reader. The text in case is read for me as every letter is separated from the others by a unpronouncible symbol and the whole line becomes a mess. Something like the chicken language, if you are acquainted with the concept.
So Elsas own comparison[1] says that the binary size difference is 20MB Elsa (QJS) vs 44MB Deno (V8). Looking at QuickJS benchmark[2] V8 is 28M vs 1M QJS, so Elsa adds 19M on top of the engine vs 16M for Deno. Doesn't feel that lightweight anymore [1] https://github.com/elsaland/elsa/blob/master/COMPARISON.md [2] https://bellard.org/quickjs/bench.html
It is amusing how each of us define our own _lightweight_, for me it is the size and readability of the code. Others it is the magnitude of the executable bytes. To someone else it might mean the startup time, the number of dependencies or the build/test/debug iteration time.
Earlier quoted context omitted.
Not all unicodes are equal for a screen reader. The text in case is read for me as every letter is separated from the others by a unpronouncible symbol and the whole line becomes a mess. Something like the chicken language, if you are acquainted with the concept.
I see, thanks for explaining. Anyway to do it in a more screen reader friendlier way?
It seems that the comparative advantage of QuickJS based solutions is short-lived invocations that benefit from fast startup times. CLI apps/tools and Cloud Functions (e.g. AWS Lambda) seem to fit the bill.
Elsa adds Deno-like HTTP imports and TypeScript support which makes it a strong alternative to Deno for CLI apps/tools.
Deno (V8 on Rust) or the rusty_v8 bindings seems like the better choice for long-lived servers where server-side JavaScript performance is important.
Earlier quoted context omitted.
That a rocket is two orders of magnitude faster than a jetliner doesn't make a jetliner not fast.
True statement, but what does that metaphor-analogy have to do with server side JavaScript runtimes? They are also not the same thing, Dragonflys are fast, but they won't run my JS either. Our systems have absolute speeds that the client requests don't care about. They don't care if they are fast for an _x_ when that _x_ has nothing to do with the client. Minimal is a nice quality, but I don't think Elsa is fast in a…
Seems pretty self-evident that there are more considerations than "literally the fastest" to be made when the decision is "how do I get from point A to point B", or in this case "how do I execute my javascript". Vehicles and runtimes can be considered fast [enough] regardless of the existence of faster options.
Also, QuickJS is not a "server-side JavaScript runtime". Not all programming is web development.
> Given Fabrice Bellards other projects, I wouldn't be surprised if a JIT landed in QuickJS.
Personally I would be pretty surprised considering that the aim of the project seems in part to be as small as possible.
Earlier quoted context omitted.
That is a horrible way to present benchmarks, but it's quite a big difference in favor of Elsa. I was under the impression Deno was built on Rust and V8 which should bode for good performance, Elsa must be doing something very good?
Each of the benchmarks seem to take a single-digit number of milliseconds in Elsa/QuickJS. My guess is that these benchmarks were chosen because the startup time for QuickJS is probably less than the startup time for V8, but I struggle to imagine that V8 is slower once the code has warmed up. Any meaningful benchmark with JIT runtimes should take several seconds, at a minimum, in my opinion. 8 milliseconds is not eno…
Maybe a benchmark for JIT runtimes, but you should always keep in mind what the expected use case is.
I recently ported a program from lang X to lang Y. It's a command-line program that you're expected to invoke in your terminal, and it processes some input and then spits something out (not unlike, say, a compiler or a static site generator) but it's expected to be used "interactively" i.e. no significant pauses for processing typical workloads, just like you expect from invoking mkdir or ls. Zero percent of the effort during porting was spent on optimization. In fact, the lang X version uses specialized, algorithmically-sophisticated collection classes, and the lang Y version does the dumbest possible thing. Despite this, for typical workloads, the Y version completes sooner than it takes the X version to do the same. No amount of benchmarking in the world is going to change the fact that the dumb Y version is faster than the clever X version.
For our program to have taken "several seconds, at a minimum" to run would have been a failure case, so there would have been no value in benchmarking that, let alone optimizing for it. I expect the use cases are the same for this project, which is supposed to be processing untrusted scriptlets that need to finish in the smallest amount of wall clock time possible.
It's a simple command-line application that dispatches to the quickjs runtime. The headline is somewhat misleading.
I don't think so, it is clearly a Deno competitor in name and spirit. My first thought was around how languages allow us to choose our tribe and that Go folks couldn't contribute to Deno since it is in Rust, hence Elsa, maybe they were getting Frozen out? Or Deno is the Dinosaur and Elsa is the ice age that kills them? Who knows, ;) I had forgotten that Fabrice Bellard also made one of his signature hacks around Java…
Deno was originally written in Go, until V8's GC was getting in the way of Go's GC, so they could always work on early versions of Deno, if they are willing to accept the problems with V8 that pushed the project to Rust.
Earlier quoted context omitted.
Each of the benchmarks seem to take a single-digit number of milliseconds in Elsa/QuickJS. My guess is that these benchmarks were chosen because the startup time for QuickJS is probably less than the startup time for V8, but I struggle to imagine that V8 is slower once the code has warmed up. Any meaningful benchmark with JIT runtimes should take several seconds, at a minimum, in my opinion. 8 milliseconds is not eno…
> Any meaningful benchmark with JIT runtimes should take several seconds, at a minimum, in my opinion. 8 milliseconds is not enough. Maybe a benchmark for JIT runtimes, but you should always keep in mind what the expected use case is. I recently ported a program from lang X to lang Y. It's a command-line program that you're expected to invoke in your terminal, and it processes some input and then spits something out…
If the goal is to compare to NodeJS and Deno, which are largely used to write long-lived servers, then I disagree entirely.
Even if the main use case for Elsa were to build Lambda-esque services, I would again disagree. Services like that gain significant benefit from reusing a single instance of the program, rather than creating it from scratch over and over again. Even without a JIT, parsing the program over and over is a waste of time, and reusing an instance allows you to amortize that cost (and the cost of JIT) across a number of uses, rather than paying that price every time.
The benchmarks provided are extremely short, such as the one-liner benchmark I mentioned before, so for all we know, QuickJS is slower at parsing JavaScript than V8 is, and it would be slower at running "real" programs than V8, even though V8 has a JIT to deal with. This is without mentioning that V8 has a JIT-less mode, which the benchmarks aren't comparing against, even though it might be more comparable.
The only use case for an 8 millisecond benchmark with startup penalty every time is interactive CLI tools, as you alluded to, and this is far from the expected use case I see described in the project.
But even then... the benchmarks showed that the startup time and total performance for V8 were comparable on the human scale. The difference between 8 milliseconds and 36 milliseconds is completely irrelevant to humans. It isn't like V8 is taking 10 seconds to initialize or something. V8 is just running slower for a short period of time as it learns about what it is executing. If the CLI tool were doing more than a non-trivial amount of work, the V8 JIT would begin to accelerate past QuickJS.
So, the benchmarks are irrelevant for the CLI use case, and irrelevant for seemingly every use case that has been presented. If the benchmarks were showing that V8 could not complete these tasks in a reasonable amount of time, then they might be showing something useful.
These benchmarks are measuring the use case of interactive CLI tools that are written in a single line of JavaScript... which is a very specific use case that I don't believe is intended to be the target market of the project.
I appreciate your anecdote, but this isn't my first time thinking about benchmarks, and these benchmarks seem pretty seriously flawed to me. This is why I made my first comment, and your comment has done nothing to negate any of the reasoning that went into my first comment.