Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Elsa – A QuickJS wrapper written in Go

github.com

Post reply on HN
Print view View original

11–20 of 69 posts

Re: Show HN: Elsa – A QuickJS wrapper written in Go

#11

Post by coder543 »

pastrami_panda wrote: post #9
faitswulff wrote: post #3

There are some benchmarks against Deno here (as JSON files): https://github.com/elsaland/elsa/tree/master/benchmarks

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

From what I can tell, the benchmark is including the startup time, and it isn't keeping the interpreter warm -- it starts a fresh instance for each iteration of the benchmark.

This is one of the benchmarks: https://github.com/elsaland/elsa/blob/master/testing/bench_s...

Literally a single line of JavaScript.

Re: Show HN: Elsa – A QuickJS wrapper written in Go

#12

Post by mkl »

coder543 wrote: post #11
pastrami_panda wrote: post #9

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…

QuickJS's own benchmarks are here: https://bellard.org/quickjs/bench.html

V8, with or without its JIT, wins hands down. QuickJS may be small and fast to start, but fast actual computations seem not to be its strength (or intended target).

Big discussion of QuickJS last year: https://news.ycombinator.com/item?id=20411154

Re: Show HN: Elsa – A QuickJS wrapper written in Go

#14

Post by Waterluvian »

coder543 wrote: post #11
pastrami_panda wrote: post #9

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…

It’s amazing watching V8s JIT warm up. And eye opening on how to measure performance when profiling. A heavy call can take 200ms, then 100, then 80, 70. And suddenly where I thought the low hanging fruit is has vanished.

Re: Show HN: Elsa – A QuickJS wrapper written in Go

#15

Post by qu4k »

Aissen wrote: post #13

@qu4k It's a shame that QuickJS isn't mentionned in the README since it does the heavy lifting. Also, why is it secure ? Is there some kind of sandboxing of the runtime that I have missed ?

README still needs some work and surely we will credit the awesome libraries that allowed us to build elsa

We plan on taking the deno route and requiring flags when running a js file to allow specific ops to be called. You can see a demo of this in our filesystem ops

Re: Show HN: Elsa – A QuickJS wrapper written in Go

#16

Post by [deleted] »

pastrami_panda wrote: post #9
faitswulff wrote: post #3

There are some benchmarks against Deno here (as JSON files): https://github.com/elsaland/elsa/tree/master/benchmarks

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?

[deleted]

Re: Show HN: Elsa – A QuickJS wrapper written in Go

#17

Post by Aissen »

qu4k wrote: post #15
Aissen wrote: post #13

@qu4k It's a shame that QuickJS isn't mentionned in the README since it does the heavy lifting. Also, why is it secure ? Is there some kind of sandboxing of the runtime that I have missed ?

README still needs some work and surely we will credit the awesome libraries that allowed us to build elsa We plan on taking the deno route and requiring flags when running a js file to allow specific ops to be called. You can see a demo of this in our filesystem ops

Ok, I understand it's secure because of the deno-style permission system, but not necessarily because it can be used to run untrusted code safely (sandboxed engine, like in chromium).

Re: Show HN: Elsa – A QuickJS wrapper written in Go

#18

Post by qu4k »

Aissen wrote: post #17
qu4k wrote: post #15

Earlier quoted context omitted.

README still needs some work and surely we will credit the awesome libraries that allowed us to build elsa We plan on taking the deno route and requiring flags when running a js file to allow specific ops to be called. You can see a demo of this in our filesystem ops

Ok, I understand it's secure because of the deno-style permission system, but not necessarily because it can be used to run untrusted code safely (sandboxed engine, like in chromium).

Correct

Re: Show HN: Elsa – A QuickJS wrapper written in Go

#19

Post by zokier »

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

Re: Show HN: Elsa – A QuickJS wrapper written in Go

#20

Post by tomp »

artagnon wrote: post #5
faitswulff wrote: post #3

There are some benchmarks against Deno here (as JSON files): https://github.com/elsaland/elsa/tree/master/benchmarks

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).
Post reply on HN