Great! I wonder if that static struct will be consuming sort of twice memory for taht type from the stack? Am I right? I have a feeling that that static type already uses on a heap pointer to the dictionary and we're adding one more. Am I right or not?
Thanks for the great video as always. I'm curious if you've done any work with the MemoryMarshal class and the ability to "project" a Span as arbitrary struct data types?
@@FastFSharp I am already down the rabbit hole working with a complex C ABI with unions and variable-length structures. Looking into this technique as a way to work with stack-allocated bytes or byte arrays for interop with minimal copying.
Interesting that readOnlyDict is suboptimal, and that inlined-functions are subject to member accessibility. Especially from an almost 20-year-old language. What’s going on here?
The F# compiler is actually inlining that code but the CLR then tries to compile the IL and it's trying to access a private member, therefore it fails.
What about [] on the indexed property getter - do you think that would have worse performance than using F# compile-time inlining? I guess the F# inline keyword would guarantee inlining whereas the attribute would make inlining likely but not guarantee it - but guarantee no mutation because the internal state would not need to be made public.
Thanks for the video! Keep it up!
Great! I wonder if that static struct will be consuming sort of twice memory for taht type from the stack? Am I right? I have a feeling that that static type already uses on a heap pointer to the dictionary and we're adding one more. Am I right or not?
Thanks for the great video as always. I'm curious if you've done any work with the MemoryMarshal class and the ability to "project" a Span as arbitrary struct data types?
I have. It's super dangerous and rarely necessary. I'll be going deeper and deeper into the darkness with this series so we'll get there 😊
@@FastFSharp I am already down the rabbit hole working with a complex C ABI with unions and variable-length structures. Looking into this technique as a way to work with stack-allocated bytes or byte arrays for interop with minimal copying.
Why not to use :> IReadOnlyDictionary interface implemented by Dictionary?
Performance. There is significant performance degradation when you hide concrete types behind interfaces.
You could hide _values with EditorBrowsableAttribute
Oh nice! I didn't know that!
Interesting that readOnlyDict is suboptimal, and that inlined-functions are subject to member accessibility. Especially from an almost 20-year-old language. What’s going on here?
The F# compiler is actually inlining that code but the CLR then tries to compile the IL and it's trying to access a private member, therefore it fails.
What about [] on the indexed property getter - do you think that would have worse performance than using F# compile-time inlining? I guess the F# inline keyword would guarantee inlining whereas the attribute would make inlining likely but not guarantee it - but guarantee no mutation because the internal state would not need to be made public.