Easwar Swaminathan

Could you please explain what problem you are trying to solve by making this change? Maybe we can have a discussion and see if the current approach is the way...

> I implemented a feature stream counts at the benchmarkmain and ran my workloads. What does this feature do? > And I have attached all of the benchmark results. [cpuProfAfter.zip](https://github.com/grpc/grpc-go/files/10253893/cpuProfAfter.zip)...

Also, could you please explain why you want to make the change that you are making? Are you seeing some performance bottlenecks when running specific workloads?

Could you please send our your changes to the benchmarking code as a separate PR. Thanks.

The problem with the approach taken in this PR is that once a really big message is received on the stream, the memory allocated for it will never be released....

> I am interested. Please let me know what the next step is so I can proceed and resolve the issue. A brief overview of the approach that we would...

Thank you for trying the `sync.Pool` approach. But, we would still not be able to accept the PR without multiple sync pools for different sized messages because this implementation has...

> @easwars Would it be possible to consider releasing this in Milestone 1.54? The ETA is crucial information that would greatly benefit the performance of my project. I would appreciate...

Also, looks like there are some merge conflicts in the benchmark files. I would be OK to move them to separate PR as well, if that makes life easier. Thanks.

Thank you very much for your contribution @hueypark and apologies for the really drawn out review process on this PR.