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
14  2016 
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.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Sugandh Jain" <su**********@nirvana-sol.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
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
On Apr 3, 9:53 am, "Sugandh Jain" <sugandh.j...@nirvana-sol.com>
wrote:
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.
Andy <an***@med-associates.comwrote:
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.
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
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
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
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Andy <an***@med-associates.comwrote:
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.
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.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
--
Posted via a free Usenet account from http://www.teranews.com
On Apr 3, 2:16 pm, Jon Skeet [C# MVP] <s...@pobox.comwrote:
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.
On Apr 3, 5:21 pm, "MBR" <n...@nospam.comwrote:
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.
Andy wrote:
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.
--
Göran Andersson
_____ http://www.guffa.com
Thanks all.
"Andy" <an***@med-associates.comwrote in message
news:11**********************@e65g2000hsc.googlegr oups.com...
On Apr 3, 2:16 pm, Jon Skeet [C# MVP] <s...@pobox.comwrote:
>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.
On Tue, 3 Apr 2007 19:23:21 +0530, "Sugandh Jain"
<su**********@nirvana-sol.comwrote:
>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.
--
Philip Daniels
On Apr 5, 10:27 am, PhilipDani...@foo.com wrote:
There is a good reason to avoid "in-line" initializers, whatever the
value you are setting - they lead to code bloat.
<snip>
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
On 5 Apr 2007 02:45:54 -0700, "Jon Skeet [C# MVP]" <sk***@pobox.com>
wrote:
>On Apr 5, 10:27 am, PhilipDani...@foo.com wrote:
>There is a good reason to avoid "in-line" initializers, whatever the
value you are setting - they lead to code bloat.
<snip>
>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)?
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.
--
Philip Daniels
On Apr 5, 11:17 am, PhilipDani...@foo.com wrote:
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)?
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...
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?
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.
many variables and so many constructors that it becomes significant,
your class is probably too big anyway.
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
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
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Keith |
last post by:
I have a number of form fields that I wish to temporarily record into
variables and pass to a small number of subsequent pages.
Is the best way to save each one to a session variable when I...
|
by: Oliver Corona |
last post by:
I am wondering if anyone has any insights on the performance benefit (or
detriment) of declaring local variables instead of referencing members.
Is allocating memory for a new variable more...
|
by: Bonj |
last post by:
I see Session variables time out after 20 minutes (or whatever number of minutes you define)
I want to have some variables that won't time out, but they only occupy very small amounts of data, say...
|
by: Dennis |
last post by:
I have a function which is called from a loop many times. In that function,
I use three variables as counters and for other purposes. I can either use
DIM for declaring the variables or Static. ...
|
by: 1944USA |
last post by:
I am re-architecting a C# application written as a multithreaded
Windows Service and trying to squeeze every bit of performance out of
it.
1) Does the thread that an object is instantiated on...
|
by: dandorey1 |
last post by:
I'm currently in the process of writing a realtime telephony
application. I've designed it with a fairly simply plugin architecture.
When I first started reading about this the general suggestion...
|
by: SM |
last post by:
I've always wonder if there is diference when declaring and
initializing a varible inside/outside a loop.
What's a better practice?
Declaring and initializing variables inside a loop routine,...
|
by: CJ |
last post by:
Hello:
We know that C programs are often vulnerable to buffer overflows which
overwrite the stack.
But my question is: Why does C insist on storing local variables on the
stack in the first...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
