Go WASM performance

[brillout]

There are some concerns about Go performing poorly with WASM (e.g. here).

What are your thoughts on this?

[jakebailey]

I haven't seen any info in these threads about how to reproduce it. I don't see why a basic example would take a full second. It doesn't help that this all is happening on Twitter where I can't view the threads without logging in either...

https://jakebailey.dev/esbuild-playground/ for example does not work that slowly for esbuild.

[jakebailey]

Also, these tests really need to disable multi threading via --singleThreaded. That hasn't been done so they are all incurring context switch costs.

I would really have liked for people to not go spread perf numbers far and wide without actually talking to us about them...

[styfle]

It looks like https://jakebailey.dev/esbuild-playground/ doesn’t do type checking?

Here’s the link from the tweet: https://tsgo.sxzz.dev/

Is there another url that uses those best practices so we can try out type checking in the browser with TS GO + WASM?

[0xdevalias]

Are all of these examples including the load time or something?

Might be..

Loading https://tsgo.sxzz.dev/ gives me like 2-3sec on their little timer; but then if I adjust the code slightly it completes in like 700-800ms.

(Completely non scientific vibes test off my iPhone)

[HerringtonDarkholme]

Hi @jakebailey! Tweet author here. I didn't mean to spread negativity on social media and am very happy to provide additional information if you need.

The code for the playground https://github.com/sxzz/typescript-go-playground
Playground itself https://tsgo.sxzz.dev/
The code I was testing in the tweet. microsoft/TypeScript#14833 (comment)

TS-go wasm is not an official product and probably the team is not prioritizing shipping a playground at the moment. But if you want some more investigation I am very happy to help here!

[jakebailey]

I stand corrected; I just tested locally in wasmtime and setting --singleThreaded makes it slower. Wow. I guess it's not heavy preemption (though Go will still preempt without us spwaning goroutines).

[Jorropo]

For context relevant issues in Go:

• cmd/compile: performance of go wasm is very poor golang/go#65440
• runtime: implement WASM-GC golang/go#63904

Copying what I've said in a response in the go slack:

Wasm support in Go works very well*.
It's just slow at basic things like loops or compute

Among other things:

• WASM lack support for JMP instructions (CFG is emulated with for continue and a huge switch statement) cmd/compile: performance of go wasm is very poor golang/go#65440
• WASM GC doesn't support interior pointers and is radical paradigm shift requiring a huge amount of compiler work to get working
• No way for arbitrary indirect jumps required to implement goroutines (emulated same way as point 1)

A lot of this could be improved by spending lots of time in the Go compiler, but this is disincentivized because new better spec like https://github.com/WebAssembly/stack-switching would reshape the whole landscape of what is possible and how it would be achieved,
And then when they show up (like wasm-gc) turns out there is one tiny design hole that makes it close to unusable ✨.
I was told tinygo is better at this, which is not surprising because they use LLVM.

As someone who touches the Go compiler, I don't think any of this is a language issue (see tinygo), it's an implementation issue due to the go compiler having been designed to target traditional assembly,
WASM is closer to a reverse engineered V8 IR than to riscv or amd64 and there have been less engineering time put into making the go compiler's backend as good than LLVM's at this.

*by that I mean, unlike what I often hear, the full language is supported, making a compiler is lot of work and gopherjs is still working on generics support for example.

[HerringtonDarkholme]

As a comparison, the esbuild wasm build is using standard go compiler, with GOARCH=wasm

And the performance is okay. Maybe it is caused by tsgo playground's compilation issue?

[Jorropo]

Do you have numbers for the exact same esbuild workload on linux / macos / windows ?

[pulsejet]

I brought this up previously here. Copying over here for completeness.

I just want to put a word of caution here - go currently emits very inefficient wasm due to some fundamental conflicts with the stack model (see golang/go#65440). There's a good chance this will be fixed with stack switching or JSPI, but that's at least a few years in the future. But as of today, performance and size of the output wasm is very bad.

Meanwhile, tinygo emits very efficient wasm by using binaryen's relooper implementation (asyncify) rather than gc's naive stack unwind-rewind. However the garbage collector in tinygo is quite naive and basically unusable in nontrivial apps (gc pauses end up being over one second for us). But it's likely that this problem is much easier to fix by using another existing implementation (see tinygo-org/tinygo#4385)

[rictic]

I was wondering at how this is looking today, and ran into https://tsgo.sxzz.dev/ which is really nice, but worryingly slow, I see ~650ms per compile on a beefy machine. However that's using the published typescript-go wasm build (a very reasonable decision given what's exposed I think), which is essentially the CLI and so it has to redo all of the work for each compile.

I hacked together a little fork of both that playground and the typescript-go repo to see what browser-based tooling like playgrounds will be able to do once the APIs are exposed to wasm, and the numbers seem quite nice, ~10-15ms most of the time, occasional dips up to 90ms (probably hitting the garbage collector). It's doing a few of the usual TS Compiler API tricks like avoiding making fresh Program objects, skipping type checking, and using isolated modules.

Check it out: https://ts-go-playground.rictic.com/

[jakebailey]

That's neat; we of course will want to do this for the playground, though I believe we will instead expose more info over LSP and then just use that directly. (Not dissimilar to #2302)

[jakebailey]

Is there a way to view the changes you had to make? tried looking at sxzz/typescript-go-playground@main...rictic:typescript-go-playground:main but it didn't seem like there were changes to Go code. I am curious what Wasm specific interop you did (if any).

[rictic]

Oh right, I need to push my typescript-go fork somewhere, I'll get to that momentarily. The code is quite hacky and prototypey, but I made a new entrypoint for the wasm build (put //go:build js && wasm at the top of the new file and //go:build !(js && wasm) at the top of the new entry point. The new golang program sticks around rather than being invoked and exiting, but just that didn't make much difference. The biggest thing was holding onto the previous Program, and calling UpdateProgram on it to get a new Program:

prevProgram.UpdateProgram usage

	// Try to reuse the existing program if we have one for the same file
	if prevProgram != nil && transpileFileName == fileName {
		// Use UpdateProgram for fast incremental update
		var updated bool
		program, updated = prevProgram.UpdateProgram(filePath, transpileHost)
		if updated {
			programReused = true
		}
	}

	// If we couldn't reuse, create a new program
	if program == nil {
		// Build a minimal ParsedCommandLine
		commandLine := &tsoptions.ParsedCommandLine{
			ParsedConfig: &core.ParsedOptions{
				CompilerOptions: transpileOptions,
				FileNames:       []string{fileName},
			},
		}

		program = compiler.NewProgram(compiler.ProgramOptions{
			Config:           commandLine,
			Host:             transpileHost,
			JSDocParsingMode: ast.JSDocParsingModeParseNone,
		})
	}

	// Cache the program for next time
	prevProgram = program

[rictic]

Ok, pushed it up to https://github.com/rictic/typescript-go-playground with the typescript-go repo as a submodule. Run ./scripts/build-wasm.sh to rebuild the wasm module. The core of the TypeScript side is https://github.com/rictic/typescript-go-playground/blob/da765f1a9493da483486b1303ae20d0730f19f27/src/worker.ts#L322-L382 and the golang side is https://github.com/rictic/typescript-go/blob/22e6299dccbed9f3d669b4a26c3cfb59b0a746ea/cmd/tsgo/main_wasm.go#L243-L360