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

C# Serialization Performance - Part II #5822

Closed
WilliamWhispell opened this issue Mar 4, 2019 · 2 comments
Closed

C# Serialization Performance - Part II #5822

WilliamWhispell opened this issue Mar 4, 2019 · 2 comments
Assignees
Labels
c# inactive Denotes the issue/PR has not seen activity in the last 90 days.

Comments

@WilliamWhispell
Copy link
Contributor

WilliamWhispell commented Mar 4, 2019

What version of protobuf and what language are you using?
Version: master
Language: C#

What operating system (Linux, Windows, ...) and version?
Windows, Linux

What runtime / compiler are you using (e.g., python version or gcc version)
MSBUILD 15

This second issue is to address the function overhead in the current serialization implementation. In, grpc/grpc-dotnet#30 it appears they are considering a redesign. I support this and feel that their is some low hanging fruit in the current design we can leverage while that project is in the works.

I propose that without requiring a complete redesign (in the short-term), we can provide an internal interface to write T[] directly to a CodedOutputStream. A Codec would provide a reader and writer like before, but also an arraywriter.

Inside CodedOutputStream, we can handle the "common case" of the buffer being large enough to handle the entire array. This would allow consumers of CodedOutputStream to set a buffer size large enough to handle an entire array if they knew one was going to be of a predictable length. This means RepeatedField serialization would improve if the array fits within the limit, or it would remain the same speed. I will follow up this issue creation with a pull request which is WIP showing a possible implementation, which yields in my profiling a 100% speedup for repeated fields of fixed size on top of the speedup introduced by pull request #5810

Copy link

github-actions bot commented May 4, 2024

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment.

This issue is labeled inactive because the last activity was over 90 days ago.

@github-actions github-actions bot added the inactive Denotes the issue/PR has not seen activity in the last 90 days. label May 4, 2024
Copy link

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please reopen it.

This issue was closed and archived because there has been no new activity in the 14 days since the inactive label was added.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c# inactive Denotes the issue/PR has not seen activity in the last 90 days.
Projects
None yet
Development

No branches or pull requests

3 participants