Performance Rules Of Thumb

A lot of developers deal with performance differently. Some care too much, trying to optimize every single piece of code they write. Some care too little, not thinking about performance at all until it is proven to be a problem. I think both of these approaches suck and usually try to find a healthy balance between them.

Below is a list of rules of thumb that i always try to keep in mind. Keep in mind that these are just rules of thumb... they are not rules that never should be broken, nor are they applicable to each and every situation. In general though, i do believe that if you keep these in mind you can avoid serious performance issues and the need to do heavy architectural refactoring in the long run. So without further ado, these are the performance-related things that i do care about while i'm writing my code:

• Be careful with anything that goes out of process (web/wcf service calls, database calls, external systems/components, ...). The cost of these calls is often higher than you'd imagine and might not become noticeable until the load on your system increases, or when you start executing these calls in long loops.
• Fetch your data in a smart manner... Never retrieve data in a loop, but retrieve it outside of the loop in a more coarse-grained manner. Sometimes it makes sense to use some joins to retrieve data, but in other cases you're better off with executing separate queries to avoid retrieving large Cartesian products. If your data layer implements caching in some way, use it in a smart manner
• Dispose objects that need it as soon as possible... Not doing this could lead to costly dangling resources and/or memory leaks... if this eventually leads to swapping/paging you end up with abysmal performance
• Don't transfer more data than you need to. Whether you're sending data over a service or you're pushing HTML to a browser, your total bandwidth and/or the client's download speed is usually limited so this could lead to slowdowns that you can often avoid. Note that i don't recommend making everything as compact as possible, but a little bit of common sense can go a long way here.
• Don't go crazy with multi-threading and asynchronous operations. While these can generally help a lot when it comes to responsiveness (and thus, the perceived 'slowness' of your application) they aren't always the perfect solution. I once saw an 'architect' run a data import process (which had to insert that data in a remote database) over 64 threads, because it was too slow in one thread. He was surprised to see that his 64-thread solution wasn't faster than his single-threaded version. I wasn't surprised at all... I suggested getting rid of the multi-threading and to batch the insert statements, which improved the situation greatly.
• Don't hold on to large sets of data for too long. A large set of data could be a lot of database records, but it could just as well be a lot of strings, or just other objects in general. Keeping these in memory for a long time prevents them from being garbage collected as soon as they can be, which can greatly increase memory pressure in your system. Be especially careful with long-running loops that iterate over large sets of data. If you no longer need the data after you've left the loop, you're often better off getting rid of each item in the set as you're done processing it.

And that's pretty much it... outside of the stuff listed above, i typically don't care about performance. I try to keep my code clean and focused, and rely on profiling to identify performance hotspots. When the profiler identifies problems, they are often more easy to solve if you've kept your code clean than it would be if you had tried to prematurely optimize in the wrong places.