Code Salad

  Home  |   Contact  |   Syndication    |   Login
  36 Posts | 0 Stories | 37 Comments | 0 Trackbacks



Image Galleries

Seemingly forever I've been working on a business idea, it's a REST API delivering content to mobiles, and I've never really had much idea about its performance. Yes, I have a suite of unit tests and integration tests, but these only tell me that it works, not how well it works. I was also about to embark on a major refactor, swapping the database from MongoDB to RavenDB, and was curious to see if that impacted performance at all, so I needed a profiler that supported IIS Express that I can run my integration tests against, and Google gave me:
Excellent. Following the above guide an instance of IIS Express and is launched, as is Internet Explorer. The latter eventually becomes annoying, I would like to decide whether I want a browser opened, but thankfully the guide is wrong in that it can be closed and profiling will continue. So I ran my tests, stopped profiling, and was presented with a call tree listing the endpoints called and allowing me to drill down to the source code beneath.
Although useful and fascinating this wasn't what I was expecting to see, I was after the method timings from the entire test suite. Switching Show to Methods Grid presented me with a list of my methods, with the slowest lit up in red at the top. Marvellous.
I did find that if you switch to Methods Grid before Call tree has loaded, you do not get the red warnings.
StructureMap was very busy, and next on the list was a request filter that I didn't expect to be so overworked. Highlighting it, the source code was presented to me in the bottom window with timings and a nice red indicator to show me where to look. Oh horror, that reflection hack I put in months ago, I'd forgotten all about it. It was calling Validate<T>() which in turn was resolving a validator from StructureMap. Note to self, use //TODO: when leaving smelly code lying around.
Before refactoring, remember to Save Profile Results from the File menu. Annoyingly you are not prompted to save your results when exiting, and using Save Project will only leave you thankful that you have version control and can go back in time to run your tests again.
Having implemented StructureMap’s ForGenericType, I ran my tests again and:
Win, thankyou ANTS (What does ANTS stand for BTW?)
There's definitely room in my toolbox for a profiler; what started out as idle curiosity actually solved a potential problem. When presented with a new codebase I can see enormous benefit from getting an overview of the pipeline from the call tree before drilling into the code, and as a sanity check before release it gives a little more reassurance that you've done your best, and shows you exactly where to look if you haven’t.
Next I’m going to profile a load test.
posted on Thursday, October 11, 2012 12:03 PM


# re: Redgate ANTS Performance Profiler 10/11/2012 2:02 PM MissDotNet
Glad you like it!

P.S. ANTS = Advanced .NET Testing System ;)

# re: Redgate ANTS Performance Profiler 10/11/2012 2:53 PM Matt Watson
I have used ANTS in the past and it has been so useful to deep dive and pinpoint CPU and memory problems.

Post A Comment