Request & Response sync.Pool usage #390
-
Is your feature request related to a problem? Please describe. High performance gRPC/Connect services need to avoid allocations for request and response messages. Describe the solution you'd like Ideally pooling is just built into connect-go so that no one has to think about it. 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. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 2 replies
-
Related planetscale/vtprotobuf#59 |
Beta Was this translation helpful? Give feedback.
-
Pooling is certainly a nice optimization, but it's error-prone in this context: no matter how we structure I'm hopeful that arenas will be a safer route to improved overall performance.
Why not use |
Beta Was this translation helpful? Give feedback.
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.
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 n…