Closed sanposhiho closed 1 month ago
/priority next-release
I give it a try. So, in short, -gc=leaking
+ module recreation increases the throughput, at least with my implementation.
I tried it at no-gc branch,
And, run some benchmarks.
OnlyFilter_xxx
runs PreFilter and Filter, while xxx
runs all extension points.Advanced_(with_normal_gc)
runs a wasm module that has a normal TinyGo GC, while Advanced
runs an examples/advanced wasm module, which is using nottinygc in Before
and using gc=leaking
in After
.$ make bench-example
goos: darwin
goarch: arm64
pkg: sigs.k8s.io/kube-scheduler-wasm-extension/internal/e2e/scheduler
BenchmarkExample_NodeNumber/OnlyFilter_Advanced/Run-12 1687575 741.3 ns/op
BenchmarkExample_NodeNumber/OnlyFilter_Advanced_(with_normal_gc)/Run-12 490719 2438 ns/op
BenchmarkExample_NodeNumber/Advanced/Run-12 33591 36176 ns/op
BenchmarkExample_NodeNumber/Advanced_(with_normal_gc)/Run-12 10000 103483 ns/op
$ make bench-example
goos: darwin
goarch: arm64
pkg: sigs.k8s.io/kube-scheduler-wasm-extension/internal/e2e/scheduler
BenchmarkExample_NodeNumber/OnlyFilter_Advanced/Run-12 53358 18770 ns/op
BenchmarkExample_NodeNumber/OnlyFilter_Advanced_(with_normal_gc)/Run-12 54272 18816 ns/op
BenchmarkExample_NodeNumber/Advanced/Run-12 12394 95442 ns/op
BenchmarkExample_NodeNumber/Advanced_(with_normal_gc)/Run-12 4820 225602 ns/op
The result in After
shows using gc=leaking
is faster than normal tinygo gc.
But, looking at the comparison between Before
and After
, Advanced_(with_normal_gc)
takes more time in After
than Before
.
We recreate modules in goroutine, so the recreation doesn't block the scheduling directly, but from this result, we can have a guess it does indirectly; a frequent recreation of modules causes the wazero runtime executing wasm functions slower somehow.
I know there could be more things that I could look into to know where is the bottleneck and possibly find out the solution for them, but, at least, it's not a low-hanging fruit.
Go is about to support wasmexport
and I'm guessing we're likely gonna move our SDK to Go base, from TinyGo base.
https://github.com/golang/go/issues/65199
Then, all the effort here could be waste after all. So, it's much better to put effort for other necessary functionalities rather than this issue, while waiting for an arrival of Go's export support.
For now, I'm closing this issue and we can reopen if necessary, when we find TinyGo GC stuff optimization necessary again.
/close
@sanposhiho: Closing this issue.
We're using a great nottinygc to reduce the cost of GC in wasm guests.
But, nottinygc is archived.
I've had an another idea for this challange coming from GC actually since before.
When api.Module is closed, I suppose all resources allocated to the module are released. And, then I'm wondering if it'd be possible to get a better performance by stopping GC on wasm module from tinygo with
-gc=leaking
flag, and instead create/delete modules every time on host side. The performance depends on how expensive creating a new guest is though.This issue intends to research that possibility, with seeking concerns around it too.