views:

688

answers:

8

Excuse me if I'm off on my terminology, I only have around 2.4 years of programming experience, mostly in .NET.

Currently I'm one of two .NET developers in a mainframe shop, the other developer set the standards and is a great coder with a lot more experience plus a CS degree(I am 100% self taught).

We use custom collections for every application, recently since .NET 2.0 I've got him using generics instead of ArrayLists, and eyeball performance they seem to do great. We developed an automated program that uses SQLDMO to connect to databases and will create the base Datalayer and business layers for any objects we'd like, plus it handles logical deletes et cetera.

When performance is what you optimize for, when can you justify NOT using a custom collection and writing a custom sort for it? Currently we use hard coded sorts because everything we've seen is a good deal slower, since most other options use reflection or bloated datasets/LINQ(is it still as slow as it was a year ago compared to custom collections?).

Does anyone else work strictly with custom generic collections instead of going the easy route? Is the performance sacrifice as significant as I have been led to believe? Being that I am still in my infant stages of my development career, I'd say the next logical step is for me to start benchmarking things myself, but I wanted to get the opinion of other professionals as well....So, how does everyone else do it? Am one of the only people who actually strictly use custom collections over the much quicker and easier to create solutions?

All opinions would be greatly appreciated.

EDIT: Sorry about the terminology, I knew I would get something a little off. What I meant by custom collections was indeed, using custom classes, and a custom collection class that inherits List(Of T) and also implements IComparable to handle sorting.

+2  A: 

I always use generic collections. I might occasionally derive my own collection class from an existing generic class to add my own methods and behaviours but it's still generic. If performance was that much of an issue you probably wouldn't use the built-in collection classes.

Ty
+2  A: 

I personally use the standard Generic collections that are out there, most commonly List and Dictionary. When possible I try to do my sorting inside the database, as I just find it a bit easier to manage.

I don't see where a custom collection is really needed, nor would it provide a performance improvement, and it makes it less familiar for implementation.

Custom collections were a lot more common before the introduction of Generics in 2.0

Mitchel Sellers
So what's the point of stuff like LINQ? If the performance is such that most people will still be using generics and classes?
thismat
That is a good point, I don't use LINQ, and we don't plan on it as we deal in too high volume where we have to do other optimizations on data retreival where LINQ to SQL just doesn't cut it. We might use it other places, like for searching/sorting at some time, but...
Mitchel Sellers
+3  A: 

I would suggest using the standard generic collections in early development. If you find a performance bottleneck later you can redesign with your own custom collections. To paraphrase Steve McConnell, author of Code Complete, human beings are notoriously bad at estimating performance. Unless you know for sure how much that class and it's methods will be accessed it's not worth optomising yet.

Martin Doms
+4  A: 

I also use generic Lists or Dictionaries, but I often make my own classes based on the generic ones. So I may define a class CustomerList : List<Customer>. This allows me to add custom functionality to the class and it also allows me to easily replace it with a custom implementation later if I need to.

Rune Grimstad
here here !! Plus, defining your own custom class allows overloaded ctors that create different collections. and client code can read much cleaner... CustomerList customersInArrears = new CustomerList(TimeSpan AcctOverdueThreshold);
Charles Bretana
+1  A: 

Custom collections may have advantages when used in interfaces because you have more control over how they can be used than you have using standard collections. Be sure to always return an interface instead of the concrete class, though. This way, your user doesn't have to care about the type of the collection class and you can change the actual type without breaking the interface.

In most cases, you'll be fine using one of the default collections.

Konrad Rudolph
+1  A: 

Now days with .net 3.5 I use generic collection classes (List, Dictionary) and if I need logic added to those collection I use extension methods. For example:

public static class Extensions { public static Customer GetCustomerByName( this List customers ) { … return customer; } }

var customers = new List(); customers.Add( new Customer()); var customer = customers.GetCustomerByName( “Smith” );

Darren C
That solution doesn't scale well, if you are linearly searching through the list of customers to find the one with the name "Smith". There you'd want to include some sort of self-keying or hash to reduce your seek time.
Marcus Griep
+4  A: 

When it comes to optimising and collections you should first look at algorithmic complexity.

A simple example is - if you have a list of objects, and you are constantly looking stuff up in that list, and it gets quite large, then you'll probably be better off using a Dictionary instead. Dictionary lookups have different lookup complexity guarantees than Lists ( between O(log n) and O(1) as opposed to O(n) ).

It's worth making yourself familiar with the algorithm complexity of the various collection classes if you have not already done so (if you're entirely unfamiliar with it, check out the wikipedia article)

If you're using an associative collection, like Dictionary, you should also check that you are using the best implementation for GetHashCode() on the objects in the collection

The trouble with .Net (caveat: I've only used up to .Net 2.0 myself so far) is that they don't have a good range of collection classes, and their complexity guarantees are not as widely known as they should be.

Personally I augment my collections with the excellent PowerCollections, which adds Sets and MultiDictionaries, amongst others. This gives you more tool to choose from, which means you can pick the right one more of the time.

As yet I have not come across a case where I have had to write a custom collection class due to poorly performing built in (or PowerCollection) collections (other than the older, pre-generic, versions). It's my feeling that if, having made sure you are using the right complexity, and having profiled, you find they are still not performant enough, then maybe .Net is not the best choice for your application. YMMV.

Phil Nash
A: 

I have recently collected a number of situations (and benchmarks) where the use of custom collections may be valuable. It is not directly related to .NET but, however, its a rather general consideration and may be helpful to decide what collection better fits the particular problem.

Array, Dictionary, Collections – Performance, Functionality, Reliability

Jens Struwe