Object management : keep alive or dispose and rebuild

[Alphapage]

Hello,

I have built an object which does some jobs on a particular server.
There can have lots of this object running concurrently.
I want to know what is the best way to optimize my application:
- keep all those objects alive in memory without any timeout (the object is
built one time per user, then disposed when the user exits).
- as I can rebuild the object, I can build the object, execute the job once,
then dispose this object each time the user asks to run a method.

The first solution costs a lot of memory, but the application will be more
responsive (the object has not to be rebuilt).
The second one will cost less memory usage (if users doesn't stress the
server).

So my question is:
Is it better free memory as soon as possible, even if the server can have
stress period or is it better to keep these objects alive to increase the
performance ?
Will the second one slow the server dramatically during a stress period ?


Thanks in advance for your help.

 

[Peter Duniho]

[...]
So my question is:
Is it better free memory as soon as possible, even if the server can have
stress period or is it better to keep these objects alive to increase the
performance ?
Will the second one slow the server dramatically during a stress period ?

It's impossible to answer the question without knowing more about your
exact situation. What areas of performance are the highest priority, how
do you expect users to use your server, what are the relative costs in
time and memory involved, what kind of hardware are you running on, which
version of Windows are you using, etc.?

Now, I'm not saying you should post the answers to all those questions
here. I'm just trying to point out that it's a fairly broad question and
this isn't really a great forum for answering that sort of thing.

Now, that said, I would say that in most situations if you are concerned
about responsiveness then the right thing to do is keep your objects
alive. You don't have to worry about idle clients consuming physical RAM
and thus interfering with responsiveness serving other clients, as Windows
will swap out to disk the memory that's not being used.

Obviously there may be a concern with respect to running out of memory
(consuming the virtual address space in the process being the most likely
concern), but IMHO that's better addressed by other means (e.g. switching
to 64-bit Windows if it's really that big of a problem). Unless your
server is serializing user access and guaranteeing that you are never
servicing more than some fixed number of users at a time, then your memory
requirement is determined by the total number of connected clients anyway,
whether or not you discard service objects when they aren't needed.

Pete