connect-go
connect-go copied to clipboard
connectrpc
Request & Response sync.Pool usage
Is your feature request related to a problem? Please describe.
High performance gRPC/Connect services need to avoid allocations for request and response messages. In the gRPC ecosystem, it's possible to pool request messages with plugins like vtprotobuf, but impossible to pool response messages, as you do not control the lifetime of the response object.
Describe the solution you'd like
Ideally pooling is just built into connect-go so that no one has to think about it. We live in a world of generics now, so this might be possible.
Describe alternatives you've considered
An alternative would be to provide callback/interface that executes when the library needs a request and is finished with a response.
Pooling is certainly a nice optimization, but it's error-prone in this context: no matter how we structure connect-go, we'd need to be completely sure that no interceptor has retained a reference to the message or any of its sub-structures. Because pooling errors are so irritating to debug, I've always avoided exposing pooled objects across team boundaries.
I'm hopeful that arenas will be a safer route to improved overall performance.
...but impossible to pool response messages, as you do not control the lifetime of the response object.
Why not use runtime.SetFinalizer? Finalizers are somewhat distasteful and have some sharp edges, but they're a good fit for this use case. You'd still need to ensure the interceptors you use don't retain references to any sub-structures, byte slices, etc., but you wouldn't need any cooperation from the connect-go runtime.
