Activator.CreateInstance() versus 'new'

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...

--
Sincerely,

David Sworder
http://www.CodeFanatic.com

"David Sworder" <gilGrissom@CSILasVegas.com> wrote in message
news:uSwckv7JEHA.2012@TK2MSFTNGP11.phx.gbl...[color=blue]
> 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.
>[/color]

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.
[color=blue]
> I really wish that C# supported generics which would make this type of
> task incredibly easy...
>[/color]
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.[color=blue]
> --
> Sincerely,
>
> David Sworder
> http://www.CodeFanatic.com
>
>[/color]

> > I really wish that C# supported generics which would make this type
of[color=blue][color=green]
> > task incredibly easy...
> >[/color]
> Generics are coming, but the support for generic construction is limited[/color]
to[color=blue]
> parameterless constructors, so its utility is there but less-so than it
> would be in many cases.[/color]


Why is that???

--
cody

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

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


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

--
cody

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

"cody" <please_dont.spam.deutronium@gmx.de> wrote in message
news:eIEFo38JEHA.1192@TK2MSFTNGP11.phx.gbl...[color=blue][color=green][color=darkred]
>> > I really wish that C# supported generics which would make this type[/color][/color]
> of[color=green][color=darkred]
>> > task incredibly easy...
>> >[/color]
>> Generics are coming, but the support for generic construction is limited[/color]
> to[color=green]
>> parameterless constructors, so its utility is there but less-so than it
>> would be in many cases.[/color]
>
>
> Why is that???[/color]

Not sure, however, last I heard the only constraint related to constructors
you could place on a generic type is new().
[color=blue]
>
> --
> cody
>
> [Freeware, Games and Humor]
> www.deutronium.de.vu || www.deutronium.tk
>
>[/color]

"cody" <please_dont.spam.deutronium@gmx.de> wrote in message
news:%233ABX$8JEHA.2456@TK2MSFTNGP12.phx.gbl...[color=blue][color=green]
>> Generics are coming, but the support for generic construction is limited[/color]
> to[color=green]
>> parameterless constructors, so its utility is there but less-so than it
>> would be in many cases.[/color]
>
>
> I read an article about generics on
> http://msdn.microsoft.com/msdnmag/issues/03/09/NET/ and this statement is
> definitely wrong.
>[/color]

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();
}
}[color=blue]
> --
> cody
>
> [Freeware, Games and Humor]
> www.deutronium.de.vu || www.deutronium.tk
>
>[/color]

> Hrm, I don't see anything at all related to generic construction here.
This[color=blue]
> 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();
> }
> }[/color]


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.

--
cody

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

"cody" <please_dont.spam.deutronium@gmx.de> wrote in message
news:uYMr3L9JEHA.3728@TK2MSFTNGP12.phx.gbl...[color=blue][color=green]
>> Hrm, I don't see anything at all related to generic construction here.[/color]
> This[color=green]
>> 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();
>> }
>> }[/color]
>
>
> 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.
>[/color]

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.
[color=blue]
> --
> cody
>
> [Freeware, Games and Humor]
> www.deutronium.de.vu || www.deutronium.tk
>
>[/color]

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

--
cody

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

"cody" <please_dont.spam.deutronium@gmx.de> wrote in message
news:eyxsoo9JEHA.2456@TK2MSFTNGP12.phx.gbl...[color=blue]
> Talking abolut generics, is there any way to contraint the type parameter
> to
> a reference type,
> that means that I cannot pass value types?[/color]

Actually, yes, Eric Gunnerson blogged about it last month:
http://blogs.msdn.com/ericgu/archive.../24/95736.aspx
[color=blue]
>
> --
> cody
>
> [Freeware, Games and Humor]
> www.deutronium.de.vu || www.deutronium.tk
>
>[/color]