Not Initializing Variables : Performance impact

[Sugandh Jain]

Hi,

The warning from Microsoft.Performance Code Analysis check that,
its not required to initialize numeric variables to zero, boolean to false
and object to null is a good one because CLR does it by itself.

I wanted to know if one does initialize fields in a class, how much of the
performance hit would it have for that same operation without a
initialization done.

Regards,
Sugandh

 

[Nicholas Paldino [.NET/C# MVP]]

Sugandh,

I can't imagine it is any impact at all. It might be one extra line of
IL at most if you are dealing with constants (like int i = 1).

I really wouldn't be worried about this kind of micro-optimization.
Pretty much any other line of your code is most definitely going to have
more impact than this.

Hope this helps.

 

[Andy]

The warning from Microsoft.Performance Code Analysis check that,
its not required to initialize numeric variables to zero, boolean to false
and object to null is a good one because CLR does it by itself.

I wanted to know if one does initialize fields in a class, how much of the
performance hit would it have for that same operation without a
initialization done.

Well, the CLR does it, and then you perform the same operation again,
so while its probably not much of an impact, executing code that
literally does nothing is probably not the cleanest code.

 

[Jon Skeet [C# MVP]]

Well, the CLR does it, and then you perform the same operation again,
so while its probably not much of an impact, executing code that
literally does nothing is probably not the cleanest code.

Doing things which are less efficient than they might be is very often
the way to more readable code.

I've certainly seen people argue (reasonably) that they'll initialise a
member variable to its default value specifically to indicate that they
expect it to be read before it may be set to another value, leaving
other variables which they expect to be set to values by the
constructor etc. Seems like a pretty reasonable thing to do, to me. As
Nicholas says, the performance impact is likely to be absolutely
negligible.

 

[MBR]

If the compiler (at least in optimized mode) treated an initializer
explicitly using the type's default value for that type as a no-op, then
they're would be no change in the behavior of the program or impact in
effeciency. Perhaps it does (I haven't checked) and the warning is just
really an ECMA to-the-spec most general case warning. At any case, it would
be surprising if even in the most contrived cases any performance hit would
be measurable. I suppose if implict memset-style memory clearing happened
en-masse at time T and explicit seperate initilaizers happened seperately at
time T+1, then there could be some hard-to-hit boundry cases where behavior
would be different.

m

 

[Mark Wilden]

I don't like unnecessary initialization because I have to read it (to make
sure the initializations are really to values like 0 and null) and then
wonder why someone wanted to execute unnecessary code.

If it's for documention, then put it in comments. That will quickly point
out how silly it is.

///ark

 

[Andy]

Doing things which are less efficient than they might be is very often
the way to more readable code.

I've certainly seen people argue (reasonably) that they'll initialise a
member variable to its default value specifically to indicate that they
expect it to be read before it may be set to another value, leaving
other variables which they expect to be set to values by the
constructor etc. Seems like a pretty reasonable thing to do, to me. As
Nicholas says, the performance impact is likely to be absolutely
negligible.

I agree, and if that's the reason for doing so its fine. I didn't
mean to imply that you should never do it. It'd also be very
reasonable to expect that those using .Net know some of the rules
about what the CLR guarantees.

As far as the original post in this thread, there is a performance
impact of re-initializing, albeit a mostly negligible one, but its
there nonetheless.

 

[Andy]

If the compiler (at least in optimized mode) treated an initializer
explicitly using the type's default value for that type as a no-op, then
they're would be no change in the behavior of the program or impact in
effeciency. Perhaps it does (I haven't checked) and the warning is just
really an ECMA to-the-spec most general case warning. At any case, it would
be surprising if even in the most contrived cases any performance hit would
be measurable. I suppose if implict memset-style memory clearing happened
en-masse at time T and explicit seperate initilaizers happened seperately at
time T+1, then there could be some hard-to-hit boundry cases where behavior
would be different.

A quick look at some optimized IL shows that the compiler doesn't
remove the statement. Possibly the .net JIT compiler does though..

If you're creating a lot of objects which have those statements it is
possible it would have a noticeable impact on performance.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

If you're creating a lot of objects which have those statements it is
possible it would have a noticeable impact on performance.

Only if your object has a very large number of member variables that you
initialise.

Eventhough creating an object instance is not very expensive in .NET,
it's still so much work that a few extra instructions in the constructor
won't make any measurable difference.

 

[Sugandh Jain]

Thanks all.

I agree, and if that's the reason for doing so its fine. I didn't
mean to imply that you should never do it. It'd also be very
reasonable to expect that those using .Net know some of the rules
about what the CLR guarantees.

As far as the original post in this thread, there is a performance
impact of re-initializing, albeit a mostly negligible one, but its
there nonetheless.

 

[PhilipDaniels]

Hi,

The warning from Microsoft.Performance Code Analysis check that,
its not required to initialize numeric variables to zero, boolean to false
and object to null is a good one because CLR does it by itself.

I wanted to know if one does initialize fields in a class, how much of the
performance hit would it have for that same operation without a
initialization done.

Regards,
Sugandh

There is a good reason to avoid "in-line" initializers, whatever the
value you are setting - they lead to code bloat.

Given a class such as this:

class Foo {
private int m_X;
private int m_Y;
private int m_Z;

private int m_A = 3;
private int m_B = 4;
private int m_C = 5;

public Foo(int a) { }
public Foo(int a, int b) { }
public Foo(string s) { }
}

The C# compiler will take the lines initializting m_A, m_B and m_C and
write them into every constructor in your class (so 3x3
initializations in this case). m_X, m_Y and m_Z show no such
behaviour. You can verify this with ILDASM.

If the product "number of initialized fields * number of constructors"
is large you have a lot of unnecessary code. For this reason I never
use inline initializers.

This is compiler-determined behaviour, not CLR determined, so it may
be different with other compilers. It wouldn't seem very difficult for
the C# compiler team to optimize this behaviour in the future by
writing a single "InitVariables" method and calling it from each
constructor.

 

[Jon Skeet [C# MVP]]

There is a good reason to avoid "in-line" initializers, whatever the
value you are setting - they lead to code bloat.

The C# compiler will take the lines initializting m_A, m_B and m_C and
write them into every constructor in your class (so 3x3
initializations in this case). m_X, m_Y and m_Z show no such
behaviour. You can verify this with ILDASM.

And why exactly is this a problem? Have you ever run into it being a
significant performance issue (or any other kind of issue)?

If the code is more readable with inline initializers, I wouldn't
hesitate to use them. The generated IL is unlikely to have any
significant impact on performance, code size etc. If you've got so
many variables and so many constructors that it becomes significant,
your class is probably too big anyway.

Jon

 

[PhilipDaniels]

And why exactly is this a problem? Have you ever run into it being a
significant performance issue (or any other kind of issue)?

Why introduce bloat unnecessarily? All that is required is that you
know how your tools behave and code accordingly. Doesn't seem like a
terrible thing to ask of a professional. When a technique is available
that is a) smaller b) more flexible c) easier to understand (see
below), why not use it?

If the code is more readable with inline initializers, I wouldn't
hesitate to use them. The generated IL is unlikely to have any
significant impact on performance, code size etc. If you've got so

It's debatable whether code would be more readable with inline
initializers, I don't think it would be, in fact I think it obscures
things. You end up with part of your construction done in the .ctor,
and part of it done elsewhere, so that one logical operation is
syntactically split up across your file. How is that better than
putting it in one method?

many variables and so many constructors that it becomes significant,
your class is probably too big anyway.

Jon

That's a null argument, my class will be as large as it needs to be.
Some need to be larger than others. It's quite easy to make a class
with 10 constructors and 50 fields.

 

[Jon Skeet [C# MVP]]

Why introduce bloat unnecessarily?

For the sake of readability.

All that is required is that you
know how your tools behave and code accordingly. Doesn't seem like a
terrible thing to ask of a professional. When a technique is available
that is a) smaller b) more flexible c) easier to understand (see
below), why not use it?

If it were easier to understand, I'd agree...

It's debatable whether code would be more readable with inline
initializers, I don't think it would be, in fact I think it obscures
things. You end up with part of your construction done in the .ctor,
and part of it done elsewhere, so that one logical operation is
syntactically split up across your file. How is that better than
putting it in one method?

As you say, it's debatable. I don't particularly mind either way - but
if someone (or a team) finds it more readable to use variable
initializers, I'd say that readability is a much more significant
factor than the code bloat.

That's a null argument, my class will be as large as it needs to be.
Some need to be larger than others. It's quite easy to make a class
with 10 constructors and 50 fields.

I can't say I've ever come across such a class without thinking it
could do with further encapsulation.

Jon

 

[Mark Wilden]

A class with 10 constructors and 50 methods may be easy to create, but it's
probably wrong. I've been doing this stuff for 17 years and I've never seen
anything close to that.

///ark