Geeks With Blogs
Kyle Burns

In this blog post I intend to capture some thoughts on code optimization in general and on how the new version of RedGate's ANTs Performance Profiler can be used to "optimize optimization".

As developer's trying first to drive business value, many latch onto the mantra "Don't optimize too early".  As with many axiom's, the spirit is right on - if you allow solving the business problem to wait while you shave milliseconds off of a process that takes minutes or you have found the best memory management technique in the world that renders your code completely unreadable, then you fail in your primary task.  A much better approach is to solve the problem in as straight-forward a manner as possible, keeping in mind standard coding practices in regards to performance and scalability.  Once you have working code that solves the business problem, you can decide if it's time to optimize.

So, why optimize something that's working and meets a business need?  In my opinion, there are two main reasons.  The first reason would be that the application is not performing to expectations.  This could be a very specific measure in the rare case where non-functional requirements actually exist that define performance metrics or general reports of "it's too slow" coming from users testing or using your application.  The second reason is that you find yourself with some spare bandwidth and schedule an optimization pass.  Either way, if you're like me you want to get the absolute best return on any investment that you put into optimization.

How do you approach optimization?  I ask this question often of people that I am interviewing and usually the reply is some variation of "well, I read the code and look for things that I know are bad, change those things, and run the code again to see if it's better".  I wouldn't want my auto mechanic being paid by the hour to do that, so why do we think it's a reasonable approach for a developer?  I think the answer lies in the fact that most developers do not have a tool to help plan optimization sessions that is easy to use and understand.  We spend a lot of time learning the facets of our trade that directly correspond to delivery, which leaves little time or desire for becoming experts in the tools that Microsoft provides.  In order for me to add an auxilliary tool to my belt, it needs to save me time and not require to become an expert in the tool itself.

I decided to start looking at Redgate's ANTS Performance Profiler 7.0 (trial downloaded from http://www.red-gate.com/products/dotnet-development/ants-performance-profiler/download) last night following a couple discussions at work last week about optimization and receiving an email about the tool.  My initial pass at the product was an evaluation against the "it just works" test.  I wanted to know if I could install the tool and without referencing any documentation profile an application and comprehend the results.  The install went as smoothly as you'd expect of any modern Windows application with the exception of having received an error message referencing the initialization of Reflector (which also installed with the trial) that I used the automated error reporting to send to Redgate.  I wrote a quick console application utilizing three different methods of building a large string ("+=" concatenization, StringBuilder, and StringBuilder initialized with a capacity equal to the size of the string that would be built).  I clicked the "start profile" button from my ANTS menu, received a message that I needed to build first, built the project, clicked the menu item again, and a couple minutes later (I made some REALLY big strings) had a an interactive report in front of me whose default view contained a timeline of performance counter information, a treegrid labeled "Call Tree" that had already expanded a "hot path" drilling down to the method using the most overall time in the application run, and a third pane that I couldn't initially tell it's use but displayed source code and metrics when I selected a method in the Call Tree (this is where Reflector comes in). 

The basic "does it just work" test passed with flying colors.  The setup work required to profile the application was no more than the setup work required to run the application and, as a "mere mortal" developer, I was able to immediately get derive value from the results with no investment in learning the tool.  I can easily see this tool paying for itself in the time saved on a single optimization session by taking the guesswork out of where the most impactful changes can be made (do I focus on the method that executes in 500ms and is called once or the one that executes in 50ms and is called 1000 times?).

I plan on spending quite a bit more time over the next week or so with this tool and dig into less trivial examples and features that actually require some study.  My next couple posts will focus on nuggets gleaned from this exploration.  If you have found any cool features of this product I'd love to hear about it as well.

Posted on Wednesday, February 29, 2012 8:54 AM | Back to top


Comments on this post: Thoughts on Optimization and a first look at RedGate's ANTs Performance Profiler 7.0

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Kyle Burns | Powered by: GeeksWithBlogs.net