NO Never
Explicitly initializing class member variables and method variables actually reduces performance in .NET.
This article explores the different types of variable initialization schemes available in .NET and the performance impact of each initialization scheme. Measurements indicate that expressly initializing variables slows object initialization by 10% and slows method calls by about 20%.
In .NET, the Common Language Runtime (CLR) expressly initializes all variables as soon as they are created. Value types are initialized to 0 and reference types are initialized to null. When you expressly initialize your variables, the compiler creates code to set the value of the variables and includes that code as part of your object initialization (for classes) or method call (for methods).
The compiler is not smart enough (Microsoft, take a hint…) to discover this duplicate initialization. Granted, if you initialize a variable to a non-default value (e.g., int A = 3;) the compiler is perfectly justified in creating the extra code. When you instantiate an object (using the new keyword) or make a method call, the following sequence happens:
1. Your variables are allocated (based on instructions from the compiler).
2. The variables are initialized by the CLR.
3. The code for the object constructor or method is executed.
The problem here is: if you explicitly initialized your variables, the constructor or method code will initialize your variables again. Is this really a problem? In many cases, the double initialization is not a problem:
If the variables are static (class variables), the initialization is done once during the entire life of the process. If the class is instantiated only a few times or the method is rarely called, the extra initialization time can be safely ignored.
- But what about those objects instantiated many times in rapid succession?
- What about those methods called thousands of times?
- What is the performance impact?
Using Visual Studio .NET 2003 in "Release" mode (with the optimizer using default settings) and running on my Win2K 1.6GHz Pentium-M machine:
Creating an object and not initializing variables ~503mSec (100%)
Creating an object and initializing on definition ~557mSec (111%)
Creating an object and initializing in the constructor ~582mSec (116%)
Calling a method and not initializing local variables ~253mSec (100%)
Calling a method and initializing variables ~316mSec (125%)
Conclusions:
- If an object is heavily used (created many times a second) – don’t initialize the variables. Not initializing shaves a nice 10% off the initialization. Obviously, if you do time-consuming and lengthy initialization in the constructor – the variable initialization time will become insignificant and lost in the noise.
- For short and quick methods which are heavily used – avoid initializing local variables to default values – just trust the CLR to do it for you.
Surprisingly, initializing variables in the constructor is a little slower than initializing on definition but this may be explained by the fact that class B has an empty constructor so the constructor calling code might be eliminated by the optimizer, saving a little time.
source: http://www.codeproject.com/KB/dotnet/DontInitializeVariables.aspx
No comments:
Post a Comment