Overhead when using this in structs
When you have automatic properties, the C # compiler asks you to call the constructor this
on whatever constructor you have to make sure everything is initialized before you access them.
If you are not using automatic properties, but simply declaring values, you can avoid using the constructor this
.
What is the usage overhead this
for constructors in structs? Is this the same as double initializing values?
Wouldn't it be advisable for you to use it if performance was the main concern for this type?
a source to share
I would recommend not using automatic properties at all for structs, as that means they will be mutable - if only confidentially.
Use readonly fields and public properties to make them available where needed. Mutable structures are almost always bad ideas and have all sorts of nasty little things.
Do you definitely need to create your own value type in the first place? In my experience, it's very rare to find a good reason to create a struct rather than a class. You may have one, but it's worth checking out.
Back to the original question: if you care about performance, measure it. Is always. In this case, it is very easy - you can write a struct using an automatic property and then override it. You can use a block #if
to make both options available. You can then measure typical situations and see if the difference is significant. Of course, I think the design implications will probably be more important :)
a source to share
Yes, the values ββwill be initialized twice, and without profiling it is difficult to tell if this performance boost will be significant.
The default constructor struct
initializes all members to their default values. After that, your constructor will run, in which you will no doubt set the values ββof these properties again.
I would imagine this would be no different from CLR practice of initializing all reference type fields when instantiated.
a source to share
The reason the C # compiler requires you to bind to the default constructor (i.e. append : this()
to the constructor declaration) when using auto-implemented properties is because all variables must be assigned before leaving the constructor. Now auto-implemented properties are a bit flawed as they prevent you from accessing variables that return properties directly. The method used by the compiler to work around this is to automatically assign all variables to their default values, and to ensure this, you must bind to the default constructor. It's not a particularly smart method, but it does the job well enough.
Indeed, this will mean that some variables will end up being initialized twice. However, I don't think this will be a big performance issue. I would be very surprised that the compiler (or at least JIT) didn't just remove the first initialization statement for any variable that is set twice in your constructor. A quick test should confirm this for you, although I'm sure you'll get the expected results. (Unless you accidentally do this, and absolutely need a slight performance boost by avoiding duplicate initialization clauses, you can simply define your properties in the normal way, i.e. with fallback variables.)
Honestly, my advice would be to not even bother with auto-implemented properties in structs. It's only okay to use public variables instead, and they offer as much functionality as automatic properties. Of course, classes are a great situation, but I really wouldn't hesitate to use public variables in structs. (Any complex properties can be defined fine if you need them.)
Hope it helps.
a source to share
Don't use automatic properties with structures. Just expose the fields directly. If a struct has a public public field of the Foo
type Bar
, then the fact that it Foo
is a public field of the type Bar
(information readily available from Intellisense) says a lot about it.On the contrary, the fact that the struct Foo
has a public read-write property for Boz
, says nothing about whether the entry in the Boz
field will mutate in the structure or whether it will mutate some object to which the Boz
reference contains. Exposing fields directly will offer cleaner semantics and also often lead to faster code.
a source to share