Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / C# / March 2008

Tip: Looking for answers? Try searching our database.

Object management : keep alive or dispose and rebuild

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Alphapage - 17 Mar 2008 12:40 GMT
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 - 17 Mar 2008 18:36 GMT
> [...]
> 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

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.