Well, after a quiet start to the day for me personally, things sure got busy later.  Things were quiet largely due to the keynote overrun, and just too many great breakout sessions to attend.  A few folks swung by the hands on labs and started using our lab.  Sadly, using VPCs with the profiler is never going to yield the same results, so we've had to publish some addenda.  Next time I'll make sure we have native images so we can drill into some sampling scenarios as well as getting good race data.

Being so quiet I managed to get caught up with some friends at Intel and AMD, as well as wandering by some of the folks in the same field as me, such as Compuware, Redgate and Avicode.  It seems like they had good traffic through the show.  It's especialy nice to see some Brits still working on tools in Britain.  Gabriel and Sean, my PM buddies, grabbed me for an impromptu interview with F5 networks.  I'm still trying to figure out how to repay them for that.  See the clip here.

Matt and I then spotted someone had left a note about "we'll debug your crash 1:1".  Intrigued, we headed up there, and although we didn't find the crash experts, we did run into Rico.  He's been doing 1:1 performance troubleshooting and guidance, so I hung out there to see if there was anything I could help with.  If you are at the show - register for some time with Dr. Perf here. Matt and I are considering the idea of some sort of "Iron Debugging" 1:1 stuff or competition int he future. If you think it's an idea - holler.  After deciding nothing was happening, and traipsing the 10 min walk back the big room, Rico calls me and says "Hey! I have someone here with a debugger question".  Another 10 mins (really - the room Rico is in seems like it's furthest from the main event) and I see the exact customer issue.  Sadly I don't think we have a way to beat it - it's the issue of evaluating functions as breakpoint conditions, but I'm going to harass the debugger team anyway.  While I'm there, Rico's performance appt chap had some questions about the tools that I was glad to answer, in particular, our relationship with the CLR profiler.  While I'm here I'll summarize for you folks just what that is. 

The CLR Profiler exists as a platform support tool.  It exists to solve one particular problem - memory usage of the CLR.  It has a rich offering of various views into the data.  When starting the VS Profiler project, we went to that team and said "we can''t integrate all of it in time - what are the most critical features?".  After much dicussion, we settled on the two additional views we support with memory profiling, one to show allocations by type and which methods allocate them, and one to show the lifetime of objects within the generational garbage collector in the desktop and server versions of the CLR (the NCF version of the CLR does not have a generational collector). Rico himself will tell you these are the hot buttons, the big tickets.  Some of the other CLRProfiler views, such as the timeline of gc activity, really do need some expert guidance in how to interpret them. In the longer term, we will add more and more features of the CLR profiler into what we do.

After finishing up there, I head back down and discover that the track lounge is now overrun.  I spend a great amount of time interacting with customers talking about all facets of team system, including all of the server questions.  The questions range from the "how much does it cost", which I have to admit - I always defer to marketing, to "how does the source code proxy work" and "when you built team system on team system, what were the cultural issues you faced".  This is why I love PDC.  After hanging out with Eric Lee, our ex-PM who is now in marketing for the product, I come back to find Matt in deep conversation with a guy who frankly has beaten our profiler to death.  This guy knows everything about the detailed "off-road" tips and tricks that we just couldn't polish enough in the product.  He had some great ideas, many of which were cut features, but some - like sampling AND collecting CPU counters at the sample time, were things we hadn't really considered.  I still don't know how we'd visualize that.  This really made my day.

I'll finish up with a plea - if you are at PDC, seek Matt and I out and ask us anything about debuggers, profilers and basically diagnosing software problems.  Add to that anything about our experiences with team system. We want to hear from you.

John