Hacker News Reader

Comment by a_lieb | Hacker News Reader

The benchmark scores [1] he gives only stack it up against other embeddable engines. It cuts those to ribbons, but can someone who's familiar with JavaScript performance weigh in on how it competes with the most popular engines like V8 and SpiderMonkey? It would be interesting if this is so fast that you could re-implement Node using QuickJS instead of V8, or even make a WebKit- or Gecko-based browser with QuickJS under the hood. Presumably a lot of the headaches with swapping in a new JS engine have to do with dependencies, and this has none.

[1] https://bellard.org/quickjs/bench.html

View on HN

I have a small, CPU-intensive benchmark which shows the performance of QuickJS to be comparable to other interpreters written in C. It's on par with MicroPython and recent versions of Ruby, and a little faster than CPython and Lua.

However, it's still 2-3x slower than the optimized, CPU-specific interpreters used in LuaJIT and V8 (with their JITs disabled), and 20-100x slower than the LuaJIT, V8 and PyPy JIT compilers.

Thanks, those were the numbers I was really interested in.

I figured there's no way it would be as fast as say V8 who has Google+others working for years to make it as fast as possible.

Not that it's a bad thing! They just have different purposes.

On my computer, running the v8 benchmarks from the QuickJS source:

-- QuickJS -- PROGRESS Richards RESULT Richards 445 PROGRESS DeltaBlue RESULT DeltaBlue 424 PROGRESS Encrypt PROGRESS Decrypt RESULT Crypto 633 PROGRESS RayTrace RESULT RayTrace 271 PROGRESS Earley PROGRESS Boyer RESULT EarleyBoyer 771 PROGRESS RegExp RESULT RegExp 180 PROGRESS Splay RESULT Splay 923 PROGRESS NavierStokes RESULT NavierStokes 1979 SCORE 549

-- v8 (node) -- PROGRESS Richards RESULT Richards 31083 PROGRESS DeltaBlue RESULT DeltaBlue 51056 PROGRESS Encrypt PROGRESS Decrypt RESULT Crypto 36692 PROGRESS RayTrace RESULT RayTrace 63343 PROGRESS Earley PROGRESS Boyer RESULT EarleyBoyer 50309 PROGRESS RegExp RESULT RegExp 7910 PROGRESS Splay RESULT Splay 22964 PROGRESS NavierStokes RESULT NavierStokes 35214 SCORE 32307

If the scoring scheme works the same as the results he shows on the site (higher is better), then V8 is still far faster than QuickJS. Which wouldn't be all that surprising since the V8 folks have spent hundreds of thousands of man-hours on optimization and JIT magic, which is something that would be hard to duplicate, to say the least, in a ~1.5MB all-interpreted engine.

We usually forget the purpose of scripting languages.

Main purpose of them is to be a glue between native calls: take output of one native function and pass it as input to other. So instead of writing ray-tracer in JS you should write it as a native function (not even in webasm).

In my Sciter (https://sciter.com) I had the similar dilemma:

Either to use a) some compileable language (of V8 with JIT) or to use b) something small but to provide easy ways to extend script by custom native functions.

I've chosen b) and so the engine that does HTML/CSS and scripting is 6 times more compact than just only V8 binaries. For an embeddable engine that is clearly better.

For browsers, where running JS and no real ways for native code execution... they MUST have V8 and the like. That also leads to Electron problems... browser engines are simply not suitable to be used as embeddable UI engines, by design.

It shows only 2~3% of V8 performance. But it enough for running simple embedded script. And thing is it meets JS standards. At starting you can embed it into your SW easily, and provide scripting functionality. And when your SW grow enough, and have heavy scripts, you can migrate to V8 since there is compatibility.

Reply on news.ycombinator.com