Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

misc/wasm: performance of runtime.gopark #56100

Closed
garet90 opened this issue Oct 7, 2022 · 2 comments
Closed

misc/wasm: performance of runtime.gopark #56100

garet90 opened this issue Oct 7, 2022 · 2 comments
Labels
arch-wasm WebAssembly issues NeedsFix The path to resolution is known, but the work has not been done. Performance
Milestone

Comments

@garet90
Copy link
Contributor

garet90 commented Oct 7, 2022

What version of Go are you using (go version)?

$ go version
go version go1.19 windows/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\ghall\AppData\Local\go-build
set GOENV=C:\Users\ghall\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\ghall\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\ghall\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.19
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\Users\ghall\Projects\garet\go.mod
set GOWORK=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Users\ghall\AppData\Local\Temp\go-build1322433840=/tmp/go-build -gno-record-gcc-switches

What did you do?

Interrupted a time.Sleep with function callbacks

The whole program:

//go:build js && wasm

package main

import (
	"log"
	"syscall/js"
	"time"
)

var animLoopJs js.Func

func animLoop(this js.Value, args []js.Value) any {
	log.Println("in anim loop")

	global := js.Global()
	global.Call("requestAnimationFrame", animLoopJs)
	return nil
}

func main() {
	animLoopJs = js.FuncOf(animLoop)

	global := js.Global()
	global.Call("requestAnimationFrame", animLoopJs)

	for {
		time.Sleep(50 * time.Millisecond)
		log.Println("in tick loop")
	}
}

What did you expect to see?

only calling one setTimeout every 50 ms

What did you see instead?

it seems that every time the program is interrupted while sleeping, it clears the timeouts and recreates them, leading to excessive amounts of setTimeout and clearTimeout calls

When logging scheduleTimeoutEvent and clearTimeoutEvent, the console is flooded with messages clearing the timeout only to recreate it moments later

On a separate, bigger, project

On another project, runtime.gopark takes up approximately 25% of execution time. Most of this is due to repeated calls of setTimeout and clearTimeout. It appears that the go runtime does a clearTimeout and setTimeout whenever it is awoken.

image

I implemented a patch that improves performance by keeping setTimeout tasks alive and counting the number of references to them:

// func scheduleTimeoutEvent(delay int64) int32
"runtime.scheduleTimeoutEvent": (sp) => {
	sp >>>= 0;
	const id = this._nextCallbackTimeoutID;
	this._nextCallbackTimeoutID++;

	const msec = new Date().getTime();
	const timeout = getInt64(sp + 8) + 1;
	const time = msec+timeout;

	this._timeoutIDs.set(id, time);

	const existing = this._scheduledTimeouts.get(time);
	if (existing != null) {
		existing.refs += 1;
	} else {
		this._scheduledTimeouts.set(time, {
			"task": setTimeout(
				() => {
					const existing = this._scheduledTimeouts.get(time);
					while (existing.refs > 0) {
						this._resume();
					}
				},
				timeout,
			),
			"refs": 1,
		});
	}
	this.mem.setInt32(sp + 16, id, true);
},

// func clearTimeoutEvent(id int32)
"runtime.clearTimeoutEvent": (sp) => {
	sp >>>= 0;
	const id = this.mem.getInt32(sp + 8, true);
	const time = this._timeoutIDs.get(id);
	this._timeoutIDs.delete(id);
	const existing = this._scheduledTimeouts.get(time);
	if (existing != null) {
		existing.refs -= 1;
	}
},

but this would ideally be fixed on the Go side

perf after above change:
image

@joedian joedian added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 10, 2022
@joedian joedian added this to the Backlog milestone Oct 10, 2022
@garet90
Copy link
Contributor Author

garet90 commented Oct 12, 2022

after more investigation it appears that the timeouts are sometimes placed +/- 1 ms when remade. Using the same setTimeout for timeouts within 1ms allows for even more gains:
image

(side note: the increase in time for requestAnimationFrame is due to the program becoming more GPU bound because the CPU finishes before the GPU now, not a problem or side effect of changing runtime.gopark)

@seankhliao seankhliao added Performance arch-wasm WebAssembly issues labels Oct 12, 2022
@gopherbot
Copy link

Change https://go.dev/cl/442995 mentions this issue: wasm: remove redundant calls to setTimeout and clearTimeout

@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels May 22, 2023
@dmitshur dmitshur modified the milestones: Backlog, Go1.21 May 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch-wasm WebAssembly issues NeedsFix The path to resolution is known, but the work has not been done. Performance
Projects
None yet
Development

No branches or pull requests

5 participants