Activator Class

  • Thread starter Thread starter Ian Frawley
  • Start date Start date
I

Ian Frawley

Hi

I have used the Activator class a number of times in my Windows apps and
Windows Services and was thinking of using it again in one of my web
services that I have been developing. I have been told that this is a bad
idea as it will greatly affect the performance of my web service. So I have
been thinking about it and all my other apps use the Activator class to
instantiate objects that hang around for the uptime of the app on start up,
whereas my web service will be using it to create and object each time it
needs one. This makes me think (obviously) that, this is where the
performance hit will take place.

So my question is: I will still be instantiating an object each time I need
one directly so will the activator class add much of an overhead to this
anyway?

If anyone knows of any useful articles on this topic I will be quite
grateful.

Regards

Ian
 
Ian said:
I have used the Activator class a number of times in my Windows apps and
Windows Services and was thinking of using it again in one of my web
services that I have been developing. I have been told that this is a bad
idea as it will greatly affect the performance of my web service. So I
have been thinking about it and all my other apps use the Activator class
to instantiate objects that hang around for the uptime of the app on start
up, whereas my web service will be using it to create and object each time
it needs one. This makes me think (obviously) that, this is where the
performance hit will take place.

So my question is: I will still be instantiating an object each time I
need one directly so will the activator class add much of an overhead to
this anyway?

The problem is simply that object instantiation with Reflection (which is
what Activator does) is much slower than direct instantiation of the same
object. In .NET 2, many things related to Reflection have been sped up
enormously, but I haven't explicitely tested the Activator to see if it's
one of the classes that work much faster now. But still, there's a great
overhead involved when creating objects dynamically.

Obviously, while this problem doesn't have anything to do with the type of
app you're writing, it'll be more pronounced the more objects you create
with this mechanism. You should probably think about two things: (1) are
you sure you really need to create all these objects dynamically? Wouldn't
there be a way around that? and (2) Could you cache and reuse objects that
you created once instead of creating them every time you need them?

Finally, the general warning: Don't just believe someone who says, "this
or that will be very slow." Things like these always depend on your exact
application, so you should make up your own mind based on some tests you
should do, as close to the final app as possible. Calculate the number of
objects you are going to create, simulate the complexity of the objects in
question, create a small test program and try it out!


Oliver Sturm
 
*snip*
The problem is simply that object instantiation with Reflection (which is
what Activator does) is much slower than direct instantiation of the same
object. In .NET 2, many things related to Reflection have been sped up
enormously, but I haven't explicitely tested the Activator to see if it's
one of the classes that work much faster now. But still, there's a great
overhead involved when creating objects dynamically.

Obviously, while this problem doesn't have anything to do with the type of
app you're writing, it'll be more pronounced the more objects you create
with this mechanism. You should probably think about two things: (1) are
you sure you really need to create all these objects dynamically? Wouldn't
there be a way around that? and (2) Could you cache and reuse objects that
you created once instead of creating them every time you need them?

Finally, the general warning: Don't just believe someone who says, "this
or that will be very slow." Things like these always depend on your exact
application, so you should make up your own mind based on some tests you
should do, as close to the final app as possible. Calculate the number of
objects you are going to create, simulate the complexity of the objects in
question, create a small test program and try it out!


Oliver Sturm

Hi

1st thanks for your reply.

I have been thinking about this quite allot and the fact that I am creating
objects on demand within a busy web service could be quite costly without
even using the Activator class. I have started thinking of possibly pooling
a set number of these objects to be used when required but the thought of
locking issues involved and also web clients sitting about until an object
becomes available is another concern. Either way I think possibly a more
elegant solution is called for.

Do you have any articles on caching objects for reuse?

Ian
 
Ian said:
I have been thinking about this quite allot and the fact that I am
creating objects on demand within a busy web service could be quite costly
without even using the Activator class. I have started thinking of
possibly pooling a set number of these objects to be used when required
but the thought of locking issues involved and also web clients sitting
about until an object becomes available is another concern. Either way I
think possibly a more elegant solution is called for.

Do you have any articles on caching objects for reuse?

You can find some stuff by googling for "object cache" or "object
pooling", but I don't have anything specific, sorry.

It won't be very difficult to write yourself, though. You need a list of
objects, which may be either taken or not. You need a thread-safe method
that can return an object from the pool. If you want the pool to be sized
dynamically, you need some kind of high- and low-water-mark checking,
either triggered by requests for objects or by timed evaluations of the
fill level of the pool. If you want the pool to instantiate new objects on
demand, you need to have an object factory that the pool can use to do
this. That's it, I think :-) Oh yeah, when you're at it, you might
implement support for Windows performance counters, so you can monitor the
pool performance from the outside :-)

I wonder if something readymade is around somewhere... I might just create
it myself, but not right now. Maybe someone else comes forward with a
suggestion?


Oliver Sturm
 
*snip*

Thanks again

I am going to put some research into object factories I think. I have a low
tech idea that will keep me up and running but what you said below makes
sence. So I think I will belt out my low tech approach and then implement a
pooling system based on an object factory but like I said I will need to do
some reading.

Thanks Oliver

Ian
 
Oliver Sturm said:
I wonder if something readymade is around somewhere... I might just create
it myself, but not right now. Maybe someone else comes forward with a
suggestion?

It sounds like the kind of thing Spring was designed for.

See http://www.springframework.net

I haven't used the .NET version, but I use the Java version all the
time - it's great.
 
Jon said:
It sounds like the kind of thing Spring was designed for.

See http://www.springframework.net

I haven't used the .NET version, but I use the Java version all the
time - it's great.

You are right, Spring has the functionality for the object pooling. I
haven't actually used it, but a look at the documentation showed me that
it should do well in this regard. Thanks!


Oliver Sturm
 
Oliver said:
You are right, Spring has the functionality for the object pooling. I
haven't actually used it, but a look at the documentation showed me that
it should do well in this regard. Thanks!

I've had another closer look at Spring.NET and I found that the
functionality is not as complete as I had initially imagined. For the fun
of it, I have now decided to create my own pool implementation as a blog
mini series - find the first part here:

http://www.sturmnet.org/blog/archives/2005/09/08/object-pooling/


Oliver Sturm
 
Back
Top