Activator.CreateInstance() versus 'new'

[David Sworder]

Hi,

I need to design a method that creates and returns a large array of
objects. The problem is that the *type* of object to create isn't know until
runtime. As a result, a parameter of type "Type" must be passed in:

IMyInterface[] CreateObjects(Type type,int numberOfObjects);

Internally this method will call Activator.CreateInstance() to create
the objects. Here's my question: Is there a significant performance penalty
to calling Activator.CreateInstance() versus using "new" to create the
objects? If so, I'll look for an alternate way to accomplish this task.

I really wish that C# supported generics which would make this type of
task incredibly easy...

 

[Daniel O'Connell [C# MVP]]

Hi,

I need to design a method that creates and returns a large array of
objects. The problem is that the *type* of object to create isn't know
until
runtime. As a result, a parameter of type "Type" must be passed in:

IMyInterface[] CreateObjects(Type type,int numberOfObjects);

Internally this method will call Activator.CreateInstance() to create
the objects. Here's my question: Is there a significant performance
penalty
to calling Activator.CreateInstance() versus using "new" to create the
objects? If so, I'll look for an alternate way to accomplish this task.

It shouldn't be significant, no. While CreateInstance will probably take
longer to execute than the equivilent new calls, it should still be an
insignificant fraction of time, even if you are generating a considerable
number of objects. Run a test and see how long it takes to create the
maximum number of objects you expect. If you are generating *alot* of
objects, then perhaps a factory is more appropriate. Instead of loading x
number of a given object, write a factory class which can create the object,
load the factory with Activator.CreateInstance, and use the factories
CreateObject method to create a new object with whatever parameters you
need. All in all the factory approach may make for cleaner code as well, and
it gives you a bit more flexibility(you could, optionally, pool objects
inside the factory, using IDisposable.Dispose to release the object, change
the concrete type simply by changing the factory code, log creations, etc).
It does require more code for a given object type, and without knowing your
situation I can't say if it would be better or not.

I really wish that C# supported generics which would make this type of
task incredibly easy...

Generics are coming, but the support for generic construction is limited to
parameterless constructors, so its utility is there but less-so than it
would be in many cases.

 

[cody]

I really wish that C# supported generics which would make this type
of

Generics are coming, but the support for generic construction is limited to
parameterless constructors, so its utility is there but less-so than it
would be in many cases.

Why is that???

 

[cody]

Generics are coming, but the support for generic construction is limited
to

parameterless constructors, so its utility is there but less-so than it
would be in many cases.

I read an article about generics on
http://msdn.microsoft.com/msdnmag/issues/03/09/NET/ and this statement is
definitely wrong.

 

[Daniel O'Connell [C# MVP]]

Why is that???

Not sure, however, last I heard the only constraint related to constructors
you could place on a generic type is new().

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[Daniel O'Connell [C# MVP]]

I read an article about generics on
http://msdn.microsoft.com/msdnmag/issues/03/09/NET/ and this statement is
definitely wrong.

Hrm, I don't see anything at all related to generic construction here. This
article says *very* little about constraints in general. As far as the
public spec definiton goes, you have

public class GenericClass<T>
where T : new()
{
public T CreateObject()
{
return new T();
}
}

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[cody]

Hrm, I don't see anything at all related to generic construction here.
This

article says *very* little about constraints in general. As far as the
public spec definiton goes, you have

public class GenericClass<T>
where T : new()
{
public T CreateObject()
{
return new T();
}
}

Oh I think I have misunderstood you.
I thought on something like that:

MyClass<int> = new MyClass<1234>();

So maybe the "generic construction" you were talking about is indeed limited
to parameterless ctors.

 

[Daniel O'Connell [C# MVP]]

Oh I think I have misunderstood you.
I thought on something like that:

MyClass<int> = new MyClass<1234>();

So maybe the "generic construction" you were talking about is indeed
limited
to parameterless ctors.

Ahh, I see. Yes, normal generic class constructors are open to whatever you
want, and from what I gather the CLR is capable of handling generic
constructors with any number of parameters, the C# team just didn't choose
to expose constraint syntax for that particular situation.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

 

[cody]

Talking abolut generics, is there any way to contraint the type parameter to
a reference type,
that means that I cannot pass value types?

 

[Daniel O'Connell [C# MVP]]

Talking abolut generics, is there any way to contraint the type parameter
to
a reference type,
that means that I cannot pass value types?

Actually, yes, Eric Gunnerson blogged about it last month:
http://blogs.msdn.com/ericgu/archive/2004/03/24/95736.aspx

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk