Best Practice for view data population?

Question

I've been working on a .NET application and experiencing a memory error (I'm a java developer that can do other things), I've been thinking about performance. What I'm posting about was not the memory problem. The memory problem just started me thinking.

I've repeated a trend in my ASP.NET application that I've used on countless J2EE applications: using Business Entities to populate drop down lists. The more I think about it, the more I don't like it. For example, on the app I'm working we have a drop down list of current projects. A project is a graph of objects. However, to create the list we pull back all of the projects, create the graph and only use the id and display name. This seems to be a terrible waste. To be fair, the dal layer is entirely hand written. The lead architect would not allow an ORM like NHibernate.

I realize that all of these objects are in GEN0 and quickly garbage collected. What worries me is that I'm taxing the GC. Ever 5% of the CPU needed to process the GC is 5% of CPU I can't use else where. This site is one of the few that I really respect. What do you all think? Is it bad to use the entity model for this? Should I create a set of IdValue objects that only house the display value and id? Would creating such a view object tier (I don't suppose this will go in the business layer) just create redundant code?

Thanks, JPD

Answer 1

Don't worry about taxing the GC, it will tune itself to your application to give you optimal performance. Yes it is best to reduce your memory footprint but I don't think it is quite as serious a problem as you imagine.

A good DAL that allows you to return only the data that you need will increase the performance of your application and will also decrease the amount of memory required by your application. But whether you use "too much" memory or not, I imagine that in most cases the GC will be able to handle it just fine.

Answer 2

An alternative approach is to create light-weight objects for your purposes. In this instance you would have a lighweight project object with only the id and display name. The decision then needs to be made over re-using the existing DAL or creating a lightweight version of the DAL.

Answer 3

I've been working on line of business .NET apps for the last few years and have yet to run into a performance problem that was resolved by trying to help the garbage collector work more efficiently.

Gathering metrics on the otherhand has been incredibly helpful for to improve performance, memory usage, etc.