Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reusing serialization buffers #4715

Closed
GiedriusS opened this issue Aug 30, 2021 · 3 comments
Closed

Reusing serialization buffers #4715

GiedriusS opened this issue Aug 30, 2021 · 3 comments

Comments

@GiedriusS
Copy link

Generated code typically does new(SomeType) now before calling SendMsg(). It allocates new memory every time that gets copied. Benchmarks show that memory usage can be reduced drastically by as much as 50% if the serialization buffers could be reused between different SendMsg() calls: thanos-io/thanos#4535.

However, SendMsg() now returns before the message is on the wire:

	// SendMsg blocks until:
	//   - There is sufficient flow control to schedule m with the transport, or
	//   - The stream is done, or
	//   - The stream breaks.

So, the previously linked PR is broken as a result. Seems like this old issue is related: #2159. But, I believe that this use case has not been considered before. Is it even possible to achieve what I am trying to do?

Someone even tried to work around this problem by using finalizers: http://www.golangdevops.com/2019/12/31/autopool/ but the performance improvements are very small with that. Could you please consider implementing this use-case again? Because it seems like it is impossible to do this with the current interface.

@zasweq
Copy link
Contributor

zasweq commented Sep 1, 2021

Duplicate of #2816.

@GiedriusS
Copy link
Author

GiedriusS commented Oct 28, 2021

@zasweq could you please provide guidance on how the community could help to push this forward? (if it is possible for outsiders to help at all)

@GiedriusS
Copy link
Author

@zasweq kind ping 🤗

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants