we built an extensive application upon the CSLA framework with about 50+ business objects.None of my BO's are implementing IDisposable. I also started running some memory tracing/profiling applications (ANTS) on the site. I've noticed several things here. Many (in fact, most) of my BO's are kept in memory up to age 15 or 18 sometimes. I expected that they would have been taken care of by GC long before age 18 or even age 10 for that matter.
So a few questions...
Can anyone help provide some advice on how to track down or how to increase the performance of Application.
please help.
Thanks for your help.
IDisposable is useful only if your objects hold references to (typically unmanaged) resources that should be freed as early as possible. If your objects only hold references to other managed objects, IDisposable is essentially useless. The only exceptions come in when you hold a reference to a large object (like a big image) or have hooked a static event or an event from some other object that is never reclaimed (like a singleton).
In an n-tier deployment, IDisposable is virtually impossible to actually use. An object can implement it, but since the object is cloned back and forth across the network it becomes nearly impossible to actually dispose all the clones of all the objects. Even without that problem, we're talking about object graphs here - entirely families of objects - and looping through an entire object graph to call Dispose() on each of them is non-trivial.
Which is why normal managed objects don't implement IDisposable - CSLA or not - it is just impractical to build your own reference tracking mechanism to make these calls - especially when they provide no value in most cases.
It is actually not recommended to implement a finalizer in managed types. That forces the GC to go through extra work to get rid of the object. In fact, it is a best practice to use IDisposable to explicitly tell the GC to ignore the finalizer, because otherwise the object remains in memory longer than anyone would like. Though you are right - if you implement IDisposable, you should implement a finalizer - if your object holds a reference to a non-managed type like a database connection or file handle. This is because, in the case that the app has a bug and doesn't call Dispose(), you still do need to properly close the unmanaged resource. But that is a last-ditch effort to overcome the fact that somebody messed up and didn't call Dipose() like they were supposed to.
If you are using a profiler, then you should be able to determine where the application is spending its time in loading the data.
You say you already know it isn't the sproc - so that's good. Is it in your DAL, where the objects are loaded with data? Is it in serialization as the objects are moved from the app server to the web server (if you are in 3-tier deployment)? Is it in the UI layer where the UI is bound to the objects and the data is used to render the HTML?
thanks Andy for your suggestion and idea.
so my point is do i implement destructor in classes ..is it good or bad or helpful.
as my application is just UI and CSLA lib. means somethg two tier application.
and i need to do memory cleanup in application.
please suggest.
thanks and waiting for your reply.
bharat
Well as Rocky said you really DON'T want to implement a Finalizer (there are no destructors in .Net), unless you have unmanaged resources, which if you're doing standard Csla stuff you likely won't.
I would really check your code where you wire up event handlers, especially if you're doing events to static / Singleton objects. The event handlers can cause objects to be kept in memory, so you really should be unhooking them when you're done with the objects. That's usually the culprit.
I've found that the CSLA and business objects I write rarely give me performance issues. If they do, it's because I've done something stupid like bring back too many rows or written some inefficient SQL statements.
Where I have had performance issues is in binding objects to WPF controls, and as the previous post said I've also had objects hang around in memory due to not unhooking the event handlers. The Red Gate tools helped me out there showing the memory tree and what was holding on to my objects (oddly it was the Infragistic control keeping the control alive, the form it was on and hence the objects that were created.
So again, that's either me not unhooking things, a control "issue" and/or WPF controls not being as quick as they could be.
Copyright (c) Marimer LLC