Benchmarks and performance data?

[mbertschler]

On average 6-7 times faster than otto. Also uses considerably less memory.

What benchmark code did you use for this, and what were the exact results?

Nice work so far :)

[dop251]

I used octane 2.0, some of the long running tc39 tests (specifically this and this).

Haven't had time to prepare the results in a publishable form, sorry.

[ohenepee]

Still haven't had the time to prepare results? Would really love to see how it stacks up against Otto and V8... how much slow it is at least compared to V8 in simple tests.

[sokolovstas]

otto parallel test
otto parallel thread : 33.652262738s

goja parallel test
goja parallel thread : 10.559833574s

benchmark otto

Box2D 89.3
Crypto 18.1
DeltaBlue 18.5
EarleyBoyer 70
NavierStokes 29.6
RayTrace 56.1
Richards 20.5
Splay 129
SplayLatency 627

benchmark goja

Box2D 509
Crypto 87.8
DeltaBlue 227
EarleyBoyer 471
NavierStokes 184
RayTrace 254
Richards 188
Splay 921
SplayLatency 4193

https://github.com/sokolovstas/fun/tree/master/go_javascript

[aidansteele]

How does it compare to Duktape wrappers, e.g. go-duktape?

[kirillDanshin]

@aidansteele it should be pretty interesting 'cause cgo adds 100ns overhead on each call

[tamasfe]

If anyone's still wondering, I ran a quick test just out of curiosity about how "go" javascript engine implementations compare.

I ran the following code a couple times:

function factorial(n) {
    return n === 1 ? n : n * factorial(--n);
}

var i = 0;

while (i++ < 1e6) {
    factorial(10);
}

The execution times roughly were:
otto: 33.195s
goja: 3.937s
duktape: 1.545s
v8 (go binding): 0.309s
v8 native (d8): 0.187s

It definitely isn't a real benchmark, and you won't really see the above lines in a real javascript code (well unless you need to calculate 10! 10^6 times for some reason 😄 ), but it should give an idea.

[tisba]

@tamasf97 out of curiosity, which v8 go binding package did you use? It's quite hard to find bindings that are not outdated/abandoned…

[tamasfe]

@tisba I don't have any of these anymore, but I'm almost certain it was this https://github.com/augustoroman/v8 . At least I remember the installation steps mentioning getting a compiled v8 from a ruby gem. Right now I don't believe there's any "proper" v8 binding around, as almost no one is interested enough in using v8 with Go from what I've seen.

[tisba]

That's too bad :( Efficient scripting support for a "static" language like Go is really nice and useful. Although I'm quite new to the ecosystem, my observation is quite similar (many, apparently abandoned projects).

[Julio-Guerra]

About "goroutine safety", is it due to a JS implementation constraint? I don't understand why every JS VM has this and cannot be used concurrently using distinct execution contexts.

[dop251]

Currently Runtime is the execution context. It has an associated VM which has stacks and other associated state, there is no way a VM could be used concurrently. Another issue is that all Object values are backed by go maps which are also not goroutine-safe. Hope that explains.

[dop251]

Besides, even if above problems were somehow solved, ECMAScript is designed to be single-threaded, there is no synchronisation mechanism and most built-in functions would break if there were concurrent modifications.

[marcsantiago]

A thought on this, couldn't the maps be mutex guarded or sync.Maps internally. Likewise, wouldn't it be possible to provide a Reset method to reset the internal state and allow the user to guard the usage with mutexes like other Go standard lib packages?

[mei-rune]

goroutine safety is unnecessary, but context support is significant. #243

[kevburnsjr]

I ran a quick test just out of curiosity about how "go" javascript engine implementations compare....

I think you'd get very different results if you ran a small script 100,000 times rather than running a big script 1 time:

function factorial(n) {
    return n === 1 ? n : n * factorial(--n);
}

var i = 0;

while (i++ < 10) {
    factorial(10);
}

[bep]

I have done some benchmarking today on the effect of reusing *goa.Program and pooling VMs here:

https://github.com/bep/gojap

[eric-gitta-moore]

Awesome proj. ths all.
But I think this might also be a good way to get familiar with the implementation of the js language, just like learning the ecma specification through quickjs.
I might be curious about the performance gap between quickjs and goja.

[ahaoboy]

I might be curious about the performance gap between quickjs and goja.

The performance of goja is only one-third of quickjs in v7-v8 test, but twice that of boa implemented in rust. For specific test data, please refer to https://github.com/ahaoboy/js-engine-benchmark

name	repo	score	platform	description
JavaScriptCore	JavaScriptCore jsc-build	46093 36.2M 1271/M	✅unix ✅macArm ✅macAmd ❌windows	JavaScriptCore is the built-in JavaScript engine for WebKit, which implements ECMAScript as in ECMA-262 specification
v8	v8.dev v8-build	45424 53.3M 852/M	✅unix ✅macArm ✅macAmd ✅windows	V8 is Google’s open source high-performance JavaScript and WebAssembly engine
bun	bun setup-bun	45203 94.5M 478/M	✅unix ✅macArm ✅macAmd ✅windows	Incredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one
node	node setup-node	37556 118.9M 315/M	✅unix ✅macArm ✅macAmd ✅windows	Node.js JavaScript runtime
deno	deno setup-deno	34866 123.6M 282/M	✅unix ✅macArm ✅macAmd ✅windows	A modern runtime for JavaScript and TypeScript
ChakraCore	ChakraCore ChakraCore-build	19973 19.4M 1029/M	✅unix ❌macArm ✅macAmd ❌windows	ChakraCore is an open source Javascript engine with a C API
spidermonkey	spidermonkey.dev spidermonkey-build	18675 38.6M 483/M	✅unix ✅macArm ✅macAmd ✅windows	SpiderMonkey is Mozilla’s JavaScript and WebAssembly Engine, used in Firefox
graaljs	graaljs	10098 199.7M 50/M	✅unix ✅macArm ✅macAmd ✅windows	A ECMAScript 2023 compliant JavaScript implementation built on GraalVM. With polyglot language interoperability support. Running Node.js applications!
hermes	hermes	1544 36M 42/M	✅unix ✅macArm ✅macAmd ✅windows	A JavaScript engine optimized for running React Native
llrt	llrt	879 11.9M 73/M	✅unix ✅macArm ✅macAmd ✅windows	LLRT (Low Latency Runtime) is a lightweight JavaScript runtime
quickjs	quickjs quickjs-build	853 4.7M 180/M	✅unix ✅macArm ✅macAmd ❌windows	QuickJS is a small and embeddable Javascript engine. It supports the ES2023 specification including modules, asynchronous generators, proxies and BigInt.
txiki.js	txiki.js txiki.js-build	830 5.2M 160/M	✅unix ✅macArm ✅macAmd ✅windows	A tiny JavaScript runtime
primjs	primjs primjs-build	764 857K 912/M	✅unix ✅macArm ✅macAmd ❌windows	JavaScript Engine Optimized for Lynx
rquickjs	rquickjs rquickjs-cli	710 1.3M 527/M	✅unix ✅macArm ✅macAmd ✅windows	High level bindings to the quickjs javascript engine
quickjs-ng	quickjs	626 2.1M 300/M	✅unix ✅macArm ✅macAmd ✅windows	QuickJS, the Next Generation: a mighty JavaScript engine
mujs-one	mujs-one	390 685K 583/M	✅unix ❌macArm ❌macAmd ❌windows	mujs by c2rust
ladybird	ladybird ladybird-js-build	386 45.2M 8/M	✅unix ✅macArm ❌macAmd ❌windows	Truly independent web browser
mujs	mujs mujs-build	368 414.5K 909/M	✅unix ✅macArm ✅macAmd ✅windows	An embeddable Javascript interpreter in C
goja	goja goja-build	274 13.2M 20/M	✅unix ✅macArm ✅macAmd ✅windows	ECMAScript/JavaScript engine in pure Go
xst	moddable	256 2.2M 119/M	✅unix ✅macArm ✅macAmd ❌windows	Tools for developers to create truly open IoT products using standard JavaScript on low cost microcontrollers
boa	boa	104 27M 3/M	✅unix ❌macArm ✅macAmd ✅windows	Boa is an embeddable and experimental Javascript engine written in Rust. Currently, it has support for some of the language.