CODEWITHSUNDEEP
c#
Matei
Matei

Reputation: 327

Constructor based object initialization

Are there significant performance differences (at runtime and/or compile time) between constructing and assigning the properties of a class like this:

Employee currentUser = new Employee();
currentUser.Name = "Bob";

or like this:

Employee currentUser = new Employee() { Name = "Bob" };

My actual example is not that simple, the properties of the class are actually assigned to some long linq expressions.

I searched Google and Stack Overflow for answers but i only found questions regarding best practices, when to use either method, and not anything performance related.

Apologies in advance if i'm asking a silly question.

Upvotes: 2

Views: 146

Answers (2)

Aliostad
Aliostad

Reputation: 81660

No. This is only a syntactic sugar. The IL generated will be the same (Will be updating with IL)

internal class Foo
{
    public string Bar { get; set; }
}
class Program
{
    static void Main(string[] args)
    {
        Foo f = new Foo()
                    {
                        Bar = "Baaz"
                    };
        Console.WriteLine("Now the old way sugar");
        Foo f2 = new Foo();
        f2.Bar = "Baaz";

    }
}

Now IL:

  IL_0000:  nop
  IL_0001:  newobj     instance void SimpleDataPlayGround.Foo::.ctor()
  IL_0006:  stloc.2
  IL_0007:  ldloc.2
  IL_0008:  ldstr      "Baaz"
  IL_000d:  callvirt   instance void SimpleDataPlayGround.Foo::set_Bar(string)
  IL_0012:  nop
  IL_0013:  ldloc.2
  IL_0014:  stloc.0
  IL_0015:  ldstr      "Now the old way sugar"
  IL_001a:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_001f:  nop
  IL_0020:  newobj     instance void SimpleDataPlayGround.Foo::.ctor()
  IL_0025:  stloc.1
  IL_0026:  ldloc.1
  IL_0027:  ldstr      "Baaz"
  IL_002c:  callvirt   instance void SimpleDataPlayGround.Foo::set_Bar(string)
  IL_0031:  nop
  IL_0032:  ret

UPDATE

OK, after comments from Jon, it is obvious that there is a slight difference. But as for the question - mainly performance implications - there is none but as Jon points out, this can be important if an object is used for its own re-creation.

Upvotes: 3

Jon Skeet
Jon Skeet

Reputation: 1499770

The two aren't quite the same. The object initializer form translates into something more like this (at least logically; I believe there are some cases where the C# compiler will just use a single variable):

Employee tmp = new Employee();
tmp.Name = "Bob";
Employee currentUser = tmp;

This is particularly important if you're ever changing the value of the variable. For example:

Employee currentUser = new Employee { Name = "Bob" };

currentUser = new Employee { Name = currentUser.Name + "Foo" };

Here the result would be an employee with a name of "BobFoo", not just "Foo" which is what you'd get if the assignment to the variable occurred before the property setter.

This could be important in other situations where the current value of the variable is read, e.g. in the property setter. Unlikely, but possible.

See section 7.6.10.2 for the details of this, where it's explicitly specified in terms of an "invisible and inaccessible temporary variable".

Upvotes: 3

Related Questions