Profiling is fun...

Back in highschool, I cut lawns for a lot of people.... so many that it was really a summer job and kept me quite busy, and then in University I took a job laying sod for a landscape company.... kinda went from the amateur level to the professional there. Both jobs were hot, dirty and left me ready for nothing but sleep at the end of a day... but I've often remarked to my wife that sometimes I long for that type of job. When you arrived at a site or a yard, it was in a bad state... it was an untidy lawn or perhaps a bare field of dirt... and at the end of the work it looked better. Not just a little bit better, but "very noticable by anyone walking by" better. I often work weeks on projects that don't produce that clear of a result... it may be better in some way, but passers-by would be hard pressed to say how... or it might not be visibly better at all, it is just cleaner under the surface or slightly more efficient....

Do I want to go back to mowing lawns or weilding a sod knife? No, but I do enjoy it when I get to work on something that fits into that model... a clear pile of work in front of me, and a noticeable result at the end. Development can be like that, although it often isn't, which may be why I enjoy it so much... but lately I get to spend less and less time coding. Well, that brings me to the actual thought that started this post; profiling is fun.

I downloaded and installed the DevPartner Profiler Community Edition ages ago, but today I started it up and then ran through a basic usage simulation of a line of business application. Quit the app and, after a bit of chugging, I had my "pile of work"; a list of the method calls where my program spent most of its execution time... with # of calls, average time per call, and %s of the whole session's time that was spent in this routine. This is all standard profiling information, but I have to admit that most of my heavy duty profiling has been done against SQL calls... using the beautiful combo of the Query Analyzer and the SQL Server Profiler. With this profiler, I was able to focus my perf work... look at each of the most expensive calls and in many cases make them take 1/3 the time. Eventually the top few methods in the list started to reflect only calls that are pretty much IO bound, which is what I expected to find. I know what some folks would say, that instead of just focusing on the worst offenders I should just improve all of my code, right? Probably, but I only have a little bit of time to spend on this.... and the profiling allowed me to make the most of that time.

Anyway, this is old news to anyone who has used a profiler (.NET or otherwise), but the community edition profiler is available for free at <www.compuware.com/media.asp?cid=3019X36>, and it is worth a try if you don't already have a profiling system in place (and doing "debug.writeline(DateTime.Now())" at the start and end of each function doesn't count).