One of the tests downloads data, but that should be disabled either way, and doubly so because the --short flag is used.

It runs in a few seconds on my laptop. I had performance issues with this package before a long time ago, but that was at compile/link time. The package has some fairly large tables included in the tests, which may be an issue (see data<Unicode_version>_test.go).

Yeah, I only see 1.9 seconds on Linux too. Must be the tables.

I can reproduce the js/wasm slowness locally with nodejs 8.11.1.

perf top says it's all spent in v8::internal::compiler::UsePosition::HintRegister. Generally pinned at 99%, sometimes dropping to 95%. I don't know how to interpret that.

And notably, I never see any output even with go test -v:

bradfitz@go:~/src/golang.org/x/text/unicode/norm$ GOOS=js GOARCH=wasm go test -v -short
^Csignal: interrupt
FAIL    golang.org/x/text/unicode/norm  19.709s

And if I add a TestMain func to just skip all tests on js/wasm, I still see it spin 100% CPU ~forever:

bradfitz@go:~/src/golang.org/x/text/unicode/norm$ git dic
diff --git a/unicode/norm/main_test.go b/unicode/norm/main_test.go
new file mode 100644
index 0000000..a7ede11
--- /dev/null
+++ b/unicode/norm/main_test.go
@@ -0,0 +1,16 @@
+package norm
+
+import (
+       "fmt"
+       "os"
+       "runtime"
+       "testing"
+)
+
+func TestMain(m *testing.M) {
+       if runtime.GOOS == "js" {
+               fmt.Fprintf(os.Stderr, "skipping on wasm\n")
+               os.Exit(0)
+       }
+       os.Exit(m.Run())
+}
bradfitz@go:~/src/golang.org/x/text/unicode/norm$ go test -short
PASS
ok      golang.org/x/text/unicode/norm  1.885s
bradfitz@go:~/src/golang.org/x/text/unicode/norm$ GOOS=js GOARCH=wasm go test -v -short
^Csignal: interrupt
FAIL    golang.org/x/text/unicode/norm  12.068s

I guess that means the Go code hasn't started to run -- all the time spent in V8 trying to compile the Wasm bytecode to machine code?

@cherrymui, oh, I hadn't thought of that. I assumed it was stuck in Go init funcs before TestMain.

For me, the WebAssembly.instantiate call in wasm_exec.js does not return in a reasonable amount of time on Node.js v11.12.0 and Chrome. It initializes quickly on Firefox, so the issue seems to be specific to V8.

Here's the wasm module if others are interested at debugging: norm.test.gz

Ben Titzer (V8 team) said we should use V8 7.4+. (so min Node.js 12.x.)

I'll update our builders.

Change https://golang.org/cl/175098 mentions this issue: env/js: update NodeJS from v8.x to v12.x

The upgrade to Node 12 didn't fix it. It's at least completing and passing on the dashboard (sometimes?) now, but it's super slow. Logs show a median of 833 seconds over the past week for running go test -short golang.org/x/text/... on js-wasm (which is Node 12).

And I can reproduce locally on my dev machines:

$ node --version
v12.2.0
$ PATH=$GOROOT/misc/wasm:$PATH GOOS=js GOARCH=wasm time go test -v -short golang.org/x/text/unicode/norm
...
(node CPU at 100% for 10+ minutes)

It is indeed the tables, but now when I run it in Chrome 75 (linux/amd64), the tests start to run immediately. So I think it's a matter of time before NodeJS catches up to the latest.

11m0s on the js-wasm builder: https://build.golang.org/log/6d190f86ce19b77eb063a09f946512ed24959ef8

Change https://golang.org/cl/202641 mentions this issue: env/js-wasm: update to Node.js v13.0

Still timing out: https://build.golang.org/log/f335ee54a276e1b0a34bfaf31336aab8ec397348

@titzer, we're using NodeJS 13 now (V8 7.8.279.17) and this is still failing for us.

Could you take a look? Or should we file a V8 bug?

Still failing. Some examples; all apparently stuck in x/text/unicode/norm (a complete list is hard to obtain due to #35515):

• https://build.golang.org/log/6b6f0c11e803678da054521b504f56604794fbc8
• https://build.golang.org/log/559f2171428abf0ccd9b68f0486bba15d476005d
• https://build.golang.org/log/274439343dc0f008ef923098d6f7efbecbba2e92
• https://build.golang.org/log/a4c9d7d49ff43c183d8c7c55ce91818f381d66db
• https://build.golang.org/log/eb3f7151fecf4193e99f40dfb8348ec4f06cfe2f
• https://build.golang.org/log/c03f4d12e772d09112d8cfa7723b2e5f07bad96f

It's not at all clear to me why the builders are not producing at least some output for the stuck test (CC @andybons).

The latest nightly of Node.js still fails to instantiate the WebAssembly module in a reasonable amount of time. It reports the following V8 version:

> node --version
v14.0.0-nightly202004175a4f24e7e1
> node -p process.versions.v8
8.1.307.26-node.12

However, Chrome 80.0.3987.163 with V8 8.0.426.30 is able to instantiate the module in a few seconds.

Node.js is using the newer V8 version, so I guess the issue is on Node.js' side, not V8's.