Benchmarks and performance data? about goja HOT 16 OPEN

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.

from goja.

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.

from goja.

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.

from goja.

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

from goja.

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

https://github.com/bep/gojap

from goja.

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

from goja.

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.

from goja.

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.

from goja.

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

from goja.

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

from goja.

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

from goja.

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

from goja.

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.

from goja.

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?

from goja.

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

from goja.

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);
}

from goja.