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 :smile: ), 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. https://github.com/dop251/goja/issues/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