Both are active now and they are diverging. It is kinda sad but Bellard seems to want to do his own thing. PRs are traded sometimes but as time goes on they will become different projects, I did suggest a name change (https://github.com/quickjs-ng/quickjs/discussions/1119)

Cool thanks for the historical context

No idea! The only benchmarks I'm aware of for QuickJS are against other JavaScript engines (https://bellard.org/quickjs/bench.html).

That said, one thing I've heard a lot from NativeScript TSC members building on top of QuickJS is that QuickJS has staggeringly low overhead for calling C functions. In fact, I was shown benchmarks in which it calls native functions faster than JS functions (perhaps it's easier to optimise because JS functions have complications like closure capture to worry about). I imagine this has conceptual overlap with how V8's Fast API works.

I embedded it at a game studio for PC and game consoles a few years ago. We opted for JavaScript over Lua for reasons I can’t disclose, but runtime performance was sufficient for our needs. I liked having reference counting since the determinism gave our tech lead a bit of confidence before cert.

We had some performance issues with marshalling and unmarshalling, but that was mostly due to API design and how our codebase was structured. As per usual, optimizing scripts was the best bang for buck.

I didnt do a formal test, but we use quickjs-ng/rquickjs as the basis for our scripting engine. Even with 20+ rust modules loaded it takes less than 4ms to spawn and we spawn a lot of them (multiple per http request that runs through the proxy).