Hi Vincent,
Are you using the CSLA undo feature in you web app? Calling the BeginEdit method directly or through the IEditableObject interface can greatly increase the size of the object graph that need to be serialized. As you may already know, the undo feature causes the children collections to be serialized into the root object internal undo stack.
Maybe this causes the size of your object graph to grow and thus slows down the serialization process.
I hope this help. Good luck,
David
For what it is worth,
I use ASP.Net State Server service and it has the same performance hit for large objects.
I try to keep the stuff in State to a minimum but sometimes I need the whole BO. When I leave the page I make sure to clear out any unused objects from Session to keep it is small as possible. (i.e. the ones that were used on the page I just left.)
Also - this idea of re-designing your BOs as all root objects is not a path I ever went down - nor will I. The whole point of these BOs is to be able to re-use them in various environments. Not have to re-design them for a web app. Things work fine when the BOs are designed the standard way.
Joe
JoeFallon1:
For what it is worth,
I use ASP.Net State Server service and it has the same performance hit for large objects.
I try to keep the stuff in State to a minimum but sometimes I need the whole BO. When I leave the page I make sure to clear out any unused objects from Session to keep it is small as possible. (i.e. the ones that were used on the page I just left.)
Also - this idea of re-designing your BOs as all root objects is not a path I ever went down - nor will I. The whole point of these BOs is to be able to re-use them in various environments. Not have to re-design them for a web app. Things work fine when the BOs are designed the standard way.
Joe
Hi Vincent, here's my tuppence:
I had a serious performance problem when binding child collections to a root object, and wanting to update the parent object's IsDirty to True whenever an object in the child collection changed. I would add an event handler in my root object to the child collections' IsDirtyChanged event. This event handler would then call the root object's MarkDirty. I had major performance problems when dealing with a child object in this scenario. Well after much head scratching and using VS2005 Team Developer Performance Tools, it turned out that this event handling was the problem. Well I still wanted my root object to report itself as dirty if any of the child collection objects were dirty. So I changed the approach by overriding the IsDirty property of the root object so that it reports a short-circuited combination of MyBase.IsDirty and also MyChildCollection(1..n).IsDirty. That was the end of those performace problems. Hope it helps with your scenario, or anyone else reading this thread?
Since your problem is related to the serialization of the object graph I tought you might be interested in this article: http://www.codeproject.com/dotnet/FastSerializer.asp.
In this two part article the author explains how to replace the standard .NET serialization process by a custom implementation that provides roughly 10 times speed imporvement and reduction of the size of the serialized data.
If this solution proves to be useful and brings better performances, maybe it could be included in some way in the CSLA framework or in a Contrib project.
davidb
Hello again. Thank you very much for all the answers. I've been through many investigations and fixes. I can now pretend that everything works "blazingly" fast. The problems were multiple. A little of all everybody posted. First, we were using beginEdit which was indeed increasing the size of the serialized objects substantially. It was not necessary to keep the undo state when navigating away from the page so I "cancelEdited" before serializing the state. Second and mostly, I implemented a small pattern which consists into releasing the child collections before navigating away from the page. A sort of active lazy load pattern. This way, when I create or edit a child object, I ask the parent to return it as Detached and I release the child collections before leaving the page to go to the child page. When I come back, the child collection gets re-fetched (lazy load) and I reattach the newly created or edited object. Using these 2 simple strategies, I could reduce the size of my serialized state from many megabytes to a maximum of 20k!!!
By the way, the business rules are always enforced on the parent object by contrast of the "all root objects" strategy which I prefer.
A little disadvantage of this strategy is that I cannot release a child collection that is dirty but that never happens in my web scenario.
Vincent.
----- Original Message -----From: ajj3085Sent: Wednesday, December 13, 2006 3:59 PMSubject: Re: [CSLA .NET] Performance problemVincent,
Glad you were able to figure things out. Just as a note, N-level undo really isn't meant to be used in web apps at all, for many of the reasons you encountered. Check out the book for more info.
Andy
Yes I know. We were using it for a journalization mechanism that provides old values and new values. But it was not necessary to keep that state when leaving the page.
Vincent.
Copyright (c) Marimer LLC