I just finished watching Mark Russinovich's TechEd Barcelona video (ok, webcast) off him demonstrating with practical examples, how to leverage the tools available in the SysInternals toolkit which as you all know is "now" (has been for 3 years?) part of Microsoft.

Additionally you can read Mark's series of posts on his blog (start here and work your way back) where he documents in the written form the same Cases he went through in the video.  One could use this as a transcript of sorts, or as a quicker practical reference over the already very good documentation.

Wanting to give this tool the appropriate spin so that it shows value not only from an IT perspective, but from a developer's perspective, I will point out that it is in my opinion more becoming of a professional developer to use due process and not conjectures when measuring the resulting product of one's work.  A number of these tools become then a convenient, well documented mechanism to capture relevant data that can then be used to support [later] efforts of optimization if it were necessary, and slowly move away from the ever present tendency to optimize prematurely... and that my friends is a lead for a thought to be further developed.

The reasons that fueled this posting, the mention of video and tools, comes as a result of one of my pet peeves, in that I see endless (and may I add pointless) discussions amongst peers surrounding the "optimal" way to code this or that solution, with granular levels as "low" as references to if property accessors are "faster" than direct references to public members.  Talk about wasted, precious processor cycles there where it really counts, and I am not talking about the physical chip/hardware, but in the truly costly developer time.

Tools like Process Explorer, with which one can look at running processes details like real time process/thread activities including the thread stack and the relationship and affinity to other processes in a very visual way, do certainly help pinpoint bottlenecks and possible memory leaks in a proactive was or from a troubleshooting stance.   I couldn't think of a more handy and easy to use tool than DebugView, another good friend to keep handy.  All in all, there is so much that can be said and so many applications that can come from the even sporadic use of this toolset.  Go ahead, before you even read any further download the suite.

So before I digress too much, I will say that I am on a mission to prove/disprove some of these premature optimization rooted blinding theories mentioned above.  My main goal is to gather usable, more "scientific" set of reference tools that may translate into the basis for sharing the learnt approach with peers, something I have not done during my previous use of the tools.  This also serves as a form of documentation and knowledge repository for myself.  Even beyond that, I will have appropriate content to post on this blog and not fear (which I think about often enough) divulging details or information that I should not most of which comes from my daily grind.