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
One of the issues I noticed is that the type models are not thread safe. Concurrent writes can collide on the underlying buffer.
To get around this I would eliminate FBE.Buffer all together and rework the serialization to use IBufferWriter and Span or ReadonlySpan for deserialization.
The Serialization method would require passing in bufferWriter.
I created an unsafe extension class that is compatible with your primative type serialization that foregoes boundary checks and is likely a lot faster.
From there I would try an inline the serialization into the generated class in order to automatically support polymorphism.
If the types were generated as immutable then the GetBufferSize() can be optimized. To make the types immutable you would need to replace arrays with IReadonlyList<T> and construct the appropriate constructors. The nice thing is that if you implement record they can mutate by copy with the with {} clause.
A PipeWriter is problematic if someone decided to use the WriteAsync because it would advance it. But your sender/receiver pattern should be reworkable to support 'Pipe`
I do have considerable experience with Roslyn code generation and can write an analyzer to generate the c# code. I just need to find the time and knowledge that I will not be the only one using it.
If your curious this is what the write looks like.
I updated the extensions to a fluent model that automatically advances.
I will add deserialization benchmarks tomorrow.
@fuocor if you'd like some help I can find time to work on this since I have great interest in this library and in the optimizations you suggested. I don't have specific experience with code generation in C# with Roslyn but I know a good deal of C#.
@alandemaria. I have a great deal of experience with Roslyn and would appreciate the help but would like the buy-in of @chronoxor before committing to the effort.
Activity
chronoxor commentedon Apr 6, 2022
I think it's possible to generate c# structs as partial if it not reduce the performance.
Also I'm thinking about experimenting with new c# records instead of structs, because:
But of course we need to create a POC and measure it's performance over strucs.
fuocor commentedon Apr 13, 2022
One of the issues I noticed is that the type models are not thread safe. Concurrent writes can collide on the underlying buffer.
To get around this I would eliminate FBE.Buffer all together and rework the serialization to use IBufferWriter and Span or ReadonlySpan for deserialization.
The Serialization method would require passing in bufferWriter.
I created an unsafe extension class that is compatible with your primative type serialization that foregoes boundary checks and is likely a lot faster.
From there I would try an inline the serialization into the generated class in order to automatically support polymorphism.
If the types were generated as immutable then the
GetBufferSize()can be optimized. To make the types immutable you would need to replace arrays withIReadonlyList<T>and construct the appropriate constructors. The nice thing is that if you implementrecordthey can mutate by copy with thewith {}clause.A
PipeWriteris problematic if someone decided to use theWriteAsyncbecause it would advance it. But your sender/receiver pattern should be reworkable to support 'Pipe`I do have considerable experience with Roslyn code generation and can write an analyzer to generate the c# code. I just need to find the time and knowledge that I will not be the only one using it.
fuocor commentedon Apr 14, 2022
Here are the serialization benchmarks when bypassing Buffer and using Span
fuocor commentedon Apr 15, 2022
If your curious this is what the write looks like.
I updated the extensions to a fluent model that automatically advances.
I will add deserialization benchmarks tomorrow.
fuocor commentedon Apr 15, 2022
fuocor commentedon Apr 15, 2022
alandemaria commentedon Nov 14, 2022
@fuocor if you'd like some help I can find time to work on this since I have great interest in this library and in the optimizations you suggested. I don't have specific experience with code generation in C# with Roslyn but I know a good deal of C#.
fuocor commentedon Nov 15, 2022
@alandemaria. I have a great deal of experience with Roslyn and would appreciate the help but would like the buy-in of
@chronoxor before committing to the effort.