Community
Perf: allow annotating SpaceTimeTypes to generate structs client-side
Currently, all SpaceTime types are converted to classes in the C# SDK. We would like to generate structs for e.g. small vectors, but currently this is impossible because information about structs vs classes is lost.
We can't simply convert all types to structs, or convert only C# server-side structs to structs, because structs behave semantically different from classes in C# and this could break clients. Instead, we can provide an annotation that a type should be a client-side struct. (For 2.0, we could make more aggressive changes.)
Activity
View on GitHub#2692Heya, would you mind if I join the discussion? As a disclaimer, I'm not a STDB employee (obviously).
I've looked at generated C# client code, all I could say is the approach is very safe.
My initial question was:
Why can't we just marshal structs directly to/from bytes?
Here is my speculations as to why:
- Decision to first support Classes as those are widely utilized by all C# devs, then add unmanaged structs eventually,
- Would not want to force everyone to use unmanaged structs?
- Has something to do with Structural changes during migrations? Probably not..
Frankly, I'm scared of Rust-side codegeneration,
Although to me it looks like the task could be trivialized to direct struct marshaling, which could be generalized to marshalling entire arrays with unsafe memcpy - which STDB is presumably organizing already on Rust side.
Why do we serialize each field separately in generated code?
I presume it is to support Classes, at all.
HPC# subset rocks, - we could fully utilize Burst compiler and Unity.Entities if STDB supported unmanaged structs in code-generated clients.
- Decision to first support Classes as those are widely utilized by all C# devs, then add unmanaged structs eventually,
