Object Pooling and CSLA Framework

295 Views Asked by At

I have an application that follows the basic methodoligy in the CSLA framework. Specificly, the objects know how to maintain their state and how to create, update, delete themselves. The car class shows this idea.

public class Car
{
    public int Color {get;set;}
    public void Drive(){.. Do something Here}
    private Car(){} // Only factory method can create this object
    public static Car New()
    {
        Car car = new Car();
        car.DataFetch();
        return car;
    }
    private void DataFetch()
    { 
        // Fill up this object with values from DB or where ever
        this.Color = repo.valueForColor();
        // ...
    }
}   

The application creates and destroys over 1 Million objects and the shear number of object creation is impacting performance due to the amount of garbage collection going on. Also a lot of these objects are completely transitory and are used to simply pass data onto the repository.

I've read about the flyweight pattern which seems like it may suit my needs. And I've also read about Object Pooling and the associated code.

What I'm having trouble with is creating a million Car objects using a pool or externalizing the data for a flyweight in conjunction with the principle of the Object should maintain it's own data and data access.

Any ideas on how to accomplish this?

1

There are 1 best solutions below

1
On

Make sure your object generation really impacts. Object generation and GC is CHEAP in sql server, and you have a database involved. IO am sure ap rofilder will show you it is NOT the object craetion and destruction that is impacting your performance, but pulling 1 million objectsin the first place.

In fact, pulling the bject should be 1000 times slower than creating the obejct AND destroying it.

Especialyl wih ridiculous inefficient code like

this.Color = dataReader.get("Color");

which is a hashtable lokoup for every car. What about storing the index of the field (or knowing it, it does not change between sql runs) and using the index? That alone will bring you more than any other approach. Especially if yuo also issue one million separate SQL Statements - as you seem to do.

Like always when doing performance optimizations: RUN A PROFILER. In your case you are 100% on the wrong idea where you are wasting your time. You will find out that object creation and gc do not even show up in the top 10 performance wasters.