I've seen for certain types of tight loops, GopherJS can produce JS code that can execute as fast as fastest C++/Go/Assembly implementation (meaning 1.0 times the time). In this case, it's around 1000.0 times the time. Which means there's an opportunity to make it up to 1000.0 times faster.

The slower performance is likely related to the following factors:

• Many, many func calls.
• mgl32.Vec2 parameters, which have underlying type of [2]float32.
• Parameters being copied by value rather than being passed by pointer.

It's related to the discussion we've had about Float32Array being used due to [2]float32 type, which seems to be much slower than other types.

I've made a reproducible standalone benchmark (with a test, to make sure func behavior is correct) and want to report it here.

https://github.com/shurcooL/play/blob/master/144/main_test.go
https://github.com/shurcooL/play/blob/master/144/main.go

Reproduce steps are:

go get -u github.com/shurcooL/play/144
go test -v --bench=. github.com/shurcooL/play/144
gopherjs test -v --bench=. github.com/shurcooL/play/144

The results on my computer are:

$ go version
go version go1.5 darwin/amd64

$ go test -v --bench=. github.com/shurcooL/play/144
=== RUN   TestColHandCheckPlayerPos
--- PASS: TestColHandCheckPlayerPos (0.00s)
PASS
BenchmarkColHandCheckPlayerPos-8     1000000          2458 ns/op
ok      github.com/shurcooL/play/144    2.507s

$ gopherjs test -v --bench=. github.com/shurcooL/play/144
=== RUN   TestColHandCheckPlayerPos
--- PASS: TestColHandCheckPlayerPos (0.02s)
PASS
BenchmarkColHandCheckPlayerPos       500       2424000 ns/op
ok      github.com/shurcooL/play/144    1.883s

Which is roughly 1000 times slower.

Note that using ColHandIsSegmentCloseToCircle2 instead of ColHandIsSegmentCloseToCircle is much, much faster for GopherJS case (but not so much for Go case). See comment for reasons explaining why:

https://github.com/shurcooL/play/blob/master/144/main.go#L109-L126