Saturday, August 20, 2011

.Net Performance and Scalability Tuning Tip #1

Measure twice, cut as many times as you like.

As promised, I am starting a series of blog posts on .Net performance and scalability tuning. I have been doing this in my current role at QSR International, and have been amazed at just how many possibilities I have found to improve the performance of the application. Each time I get to a point where I think I can’t get any more performance out of it, I find something else, or have another idea. Not all of these tips are specifically .Net related, many of them will be applicable to any programming language, but my focus for the past 7 years of my career has been specifically on .Net, so naturally, I will be focussing fairly heavily on that. These tips will also be fairly heavily “Rich Client” based as that's where I have spent most of my career, however some of these tips will also apply to any .Net code running anywhere.

My first tip is simple. Measure what you are trying to tune. You’ll probably see many bugs in your bug tracking system (you do use a bug tracking system right? If not I suggest you stop reading this article right now, and go find yourself a bug tracking system ASAP), that read “Application is slow when I do XYZ” or “Opening form foo takes forever”. The first step is to get this quantified. Exactly how many seconds does it take to do ‘X’, where ‘X’ is repeatable. Testers will probably have a set of test data, and you need to get your hands on this. Often performance issues surface because the data is structured in a specific way, and if you have differently structured data you may well not spot the problem (have a free “Works on My Machine Certification”). Once your testers have measured it, then you might want to start a discussion around what is acceptable, what you should be aiming for in the tuning etc….

Now I said “Measure twice”, well, after the testers have got some basic timings that you can use for comparisons at the completion of your tuning, then it’s your turn to measure. There are a number of tools that will analyse your code and assist in highlighting the areas that require the most attention. Visual Studio comes with a performance wizard under the “Analyze” menu. This is a reasonably good starting point, but personally I prefer tools with a nicer UI. My current favourite at the moment is “ANTS Performance Profiler” from redgate, but there are others out there (Feel free to leave a comment if you have another preference).


For me the visualizations provided by ANTS Performance Profiler allow me to very quickly and effectively focus my attention. Without this knowledge, you can spend a lot of time optimizing bits of code that are called so infrequently that even optimized won’t make any noticeable difference to the overall performance. Once you’ve picked a measuring tool, learn it and master it. I usually like to take a series of measurements as I go. As you improve the performance of one problematic area, others will start to rear their ugly heads. Also a series of good visualizations can make for some good discussions with management if they want to know how you’re going. it is also a good education tool for other developers in your team. You can show them exactly why you should, or shouldn’t do particular things.

Now that you have measured twice, unlike carpentry where the proverb “Measure twice, cut once” comes from, as coders, we can cut as many times as we need. Assuming you are using a decent source control system (and by the way, if you’re not, stop reading this article and go get yourself one NOW), you can confidently try different options to your hearts content. Keep in mind that sometimes release code behaves slightly differently to debug code, and as such, your final sign off should come from the testers testing on the release version of your build.

Stay tuned, much more to come.

Long Time No Blog

For various reasons, I haven’t blogged much over the past few years, but now I feel inspired to get back into it. A lot has changed in my professional life since I last put pen to paper (or rather ascii to screen), but a lot still stays the same.

My last post “Enjoying my iPhone” is an indication of just how long it has been. I now use a Windows Phone 7 device, and I am really liking it. To me the iPhone UX was starting to feel a little stale, and while it was revolutionary for its time, I think MS have made a real challenge with their “metro themed” UX. Having said that, I still keep my old iPhone around just in case. My biggest gripe with my HTC HD7 is that it only has 16GB of memory (my iPhone 3GS had 32GB), and as such I can’t store my entire music collection on it.

The biggest news however, is that I no longer work for Readify. As much as I love Readify, and felt honoured working along side some of Australia’s and even the world’s best geeks, I got to a point where I really needed something different. I now work for an ISV called QSR International. They write an awesome piece of software for qualitative data research called NVivo that is used in universities and research institutes all around the world. I have been working with QSR since April this year, and so far really enjoying it. It’s partly the work that I have been doing with them that has inspired me to post a series of new blog articles on .Net performance tuning, so keep a look out for that.

In other non-geek related news, the inadequacies of the Melbourne public transport system have finally caused me to give up on my hippy car-free lifestyle, and join the masses who are forced to own a car… well almost.


I am now the proud owner of a Honda CBR 600 F4i (named Xena), and absolutely love her. Although I do still catch the bus a fair bit as I believe that it increases significantly my chances of surviving the journey.

Keep a eye out for my series on .Net performance tuning… coming soon… I promise.