I was watching a medical drama the other day, you probably know the one, where the diagnostician darn near kills the patient with bizarre tests in trying to figure out his illness, given a strangely conflicting set of symptoms. I've come across some similar situations with my inorganic patients recently which forced me to step back and look at the whole patient rather than the symptoms presented.

The code profiling tool that I provide support for basically works by loading one of our DLLs into the process being profiled, and there is a possibility for the process to crash or hang with our DLL hooked in when it runs perfectly fine without it. Previously, my focus was strictly on finding bugs in our DLL, but I have come to believe that this is a pretty narrow-minded approach.

Everybody over age five has heard of the proverbial camel with the lumbar malady upon which a straw too many had been loaded, causing the camel to exhibit a lack of structural integrity. Well, that's how I would word it in my bug report because I'm a stickler for the specifics.

The metaphor is a good one, though. A programmer will notice poor performance or memory usage in his application and try to find the problem using our code profiler to gather information about slow methods or poor memory allocation, so a 'sick' application is going to have to carry the additional strain of loading our dll and all of its' requirements of memory and processing time along with it. It doesn't take a master engineer to realize that this might fail for more basic reasons than a bug in our code.

This is similar to a medical case in the respect that the patient needs to be fit enough to survive a procedure that may cure the underlying problem. If a patient needs an angioplasty and presents to surgery with nervous problems, the nervous system would need to be stabilized first so he isn't flopping around on the operating table like a fish out of water while surgeons try to fix a delicate artery wall.

I'd like to say that our code profiler is the tool to help cure to all performance problems, but sometimes other diagnostic tools need to be employed to point at the serious problems first so that the code profiler can be used to find inefficient code.

In one instance, a case came to my attention where a program appeared to hang while being profiled. Sure, profiling introduces some overhead, but this was extreme (the spash screen stayed up for an hour!). I'd suggested using performance counters, specifically the .NET CLR Memory->% Time spent in GC while profiling, and found that the application was spending 90% of its' processing time just cleaning up objects in its' own memory! Without profiling, this went down to a 'respectable' 80%. This application was in too bad a shape to be profiled because it had so many objects containing self-references. Simply adding more data to the application could reproduce the hang even without profiler, so this patient was clearly running out of time.

In rare cases, it's time to wield computing's least understood tool: the debugger. But first we will need a crash or hang dump from the customer produced using adplus.vbs from the Windows Debugging Tools suite. This produces a big, fat file containing the memory of the application, including the .NET runtime, so it's seldom to have a customer who is willing to upload a 50MB file to us. I can use windbg to analyze what happened at the time of failure. It's a dark art, but can reveal interesting information about the application. This MSDN blog is probably the most useful resource I've found on how to use the Windows Debugger.

Another common remark from customers is that although the code profiler shows minimal memory usage by their applications, the total space as reported by Task Manager is monumentally huge. In this case, you may not need to worry about optimizing your code, which is what a code profiler helps to do, but rather you want to examine the process memory space and have a look at how many modules are loaded into it. Then it's a question of perhaps ridding yourself of unused references or using alternative components in your code that are smaller. A simple, free tool for doing this is Red Gate Memory Tracker, which will give you a graphical representation of what is loaded into memory. Cleaning up this memory first may give the code profiler a bit more 'elbow room' if the problem is a shortage of memory.

Once the critical problems in an application are sorted out, then the task of enhancing the application performance is much easier!