You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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.
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
The text was updated successfully, but these errors were encountered: