I also wondered this. I suspect that, like a lot of Go code, the gRPC internals are nonchalant about starting goroutines for fairly small things, because Go's s

I also wondered this. I suspect that, like a lot of Go code, the gRPC internals are nonchalant about starting goroutines for fairly small things, because Go's scheduler is quite good. In the single-core case this may therefore involves a lot of goroutine switches. Go moves up the list rapidly in the 2 and 3 core case - the 99th percentile is pretty bad, and I'm not too surprised because Go has a GC, and my experience is that gRPC in Go does a lot of interfaces/reflection wrapping and makes a lot of garbage - the requests / responses are not pooled and at least in our gRPC APIs, the response often contains enough slices of the request I expect it keeps most of both around for too long.