Performance concerns of instantiating a class multiple times

Question

I'm wondering the performance differences between instantiating a class once in a form or whenever it is needed. For example, say I have a customer form to edit a customer. On the form load, I instantiate a customer class and call a function to return the customer data to populate the form controls.

CustomerInfo customer = new CustomerInfo();
CustomerDetail  cust = customer.GetCustomer(customerId);
txtName. cust.Name;
...

Also on the form there is a save button. When that button is clicked, I create another instance of the Customer class to update the data.

CustomerDetail cust = new CustomerData();
cust.Id = customerId;
cust.Name = txtName.Text;

CustomerInfo customer = new CustomerInfo();
customer.Update(cust);

I know this works fine. However, is it better, performance wise, just to create a single instance of the Customer class for the whole form to call both GetCustomer and Update? I know the GC will take care of those instances, but I'm not sure it would destroy the first instance before going on to the next.

Also, this example I use just two function calls to customer class, but, really, there could be more.

Thanks for the help.

Answer 1

I would move that functionality to a CustomerRepository class and have a single instance of that in my application, created when the form is created/loaded

ie. the Get/Save customerdata code.

Answer 2

The idea should be that you create an instance of Customer for every distinct customer that you are manipulating. So if your form only deals with a single customer then you should have only one instance, but if your form deals with multiple customers then you will have multiple instances.

In terms of performance, that only becomes an issue if you are dealing with many instances, I would say thousands.

Answer 3

The approach of one single instance is useful when you need to Update OR Create a "Customer" using the same Form.

Answer 4

Personally I would keep the instance around with the form. Instantiating it over and over again seems like unnecesary overhead. I agree with Vincent Ramdhanie that the idea is to have one instance per customer, so if you change customer you should get a new instance.

Also by keeping the instance around you can easily check if it actually changed, something I tend to do if there's considerable overhead in persisting changes. But that's another issue.

Answer 5

Certainly there's less overhead to not re-create the objects. Also, there may be some level of implicit locking of the data while you hold the object (otherwise you need some sort of external locking of the data, if anyone else can access the database, or unless you don't care about update-collisions).

Also, doing it the way you have above assumes that your form knows all the fields that are part of CustomerData - you didn't keep the original object around and update it, so you better make sure you got all the data out of it and transferred it by hand to the "new" object. And then your code becomes very tightly tied to the definition (and implementation) of CustomerData - if someone adds a visible field, your code needs revising. If they add a 'hidden' field or state, then your code really needs revising.

So I advise keeping the object and updating it, and separately (as needed) dealing with any locking requirements.

Answer 6

Premature optimization is the root of all evil.

NEVER consider optimization until you have a solution coded for optimum readability and find it insufficient to pass a test that tests a customer specification.

If your optimization does not then pass the same test that failed with the unoptimized version, revert it.