x/text/unicode/norm: tests run over 10 minutes and time out on js/wasm

[bradfitz]

What's so hard about x/text/unicode/norm that makes it kill js/wasm?

https://build.golang.org/log/275a5abfdca723fd4574927bd1e076ee93e04ee8

...
ok  	golang.org/x/text/search	7.146s
?   	golang.org/x/text/secure	[no test files]
ok  	golang.org/x/text/secure/bidirule	11.127s
ok  	golang.org/x/text/secure/precis	13.066s
ok  	golang.org/x/text/transform	13.374s
?   	golang.org/x/text/unicode	[no test files]
ok  	golang.org/x/text/unicode/bidi	10.438s
ok  	golang.org/x/text/unicode/cldr	11.382s
*** Test killed with quit: ran too long (10m0s).
FAIL	golang.org/x/text/unicode/norm	600.299s
ok  	golang.org/x/text/unicode/rangetable	32.598s
ok  	golang.org/x/text/unicode/runenames	11.347s
ok  	golang.org/x/text/width	9.961s

/cc @neelance @cherrymui @mpvl

[mpvl]

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

[bradfitz]

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

[bradfitz]

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.

[bradfitz]

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

[cherrymui]

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?

[bradfitz]

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

[neelance]

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.

[bradfitz]

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

[bradfitz]

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

I'll update our builders.