vmg
commented
3 years ago How is this intended to work for the other way around though?
Sadly, because of the way the GRPC APIs work, this cannot be made to work the other way around: the GRPC library takes ownership of an object once you try to send it over the wire, and delays the marshaling asynchronously. We have no way to know when the object has been fully marshaled, and hence there is no way to know when it can be safely returned to the pool.
Your best option, if you're really seeing a lot of GC churn while marshaling objects, is switching from GRPC to DRPC. I know it's not a trivial change, but DRPC is mostly a drop-in replacement and its APIs do support pooling in both directions.
Cheerios!
I have a couple of questions regarding pooling and gRPC that I could not fully understand from existing issues or the readme. (happy to do a PR to clarify in the readme after understanding for the next person)
In https://github.com/planetscale/vtprotobuf/issues/16#issuecomment-878939364 it was mentioned, that memory-pooled objects are automatically unmarshaled using objects from a pool, which I could get to work. How is this intended to work for the other way around though? Does it happen automatically somewhere like during marshaling (if so I can't find the code that does this)? If not, is there a recommended or suggested place where this could be done (maybe in the codec?)
My use case is I have a lot of objects that I read from a key-value store that eventually end up in a gRPC response, but after marshaling the response I would like to return the objects to the pool.