This week, we were fortunate enough to have Brad Abrams, Kit George, Jason Zander, and Claudio Caldato visit with us.  Claudio has got to get a blog, because this guy is just flat-out smart... the more I talked with him, the more I realized that there is a lot I have to learn about the CLR.  We had the team visit customers ranging from J2EE zealots to bleeding-edge .NET adopters to hear everything about what customers really think about .NET. 

One of my favorite discussions occurred at a customer site regarding OR mappers.  I firmly side with Ted Neward on this one, but I wanted to hear someone else's opinion, especially from people who have obviously considered this space multiple times.  The problem with OR mappers regards scale: they are fantastic for gaining a productive edge for small apps, but quickly break down for enterprise sites with millions of hits per day.  Simply put, they just don't tend to scale, and scaling them requires more than enough work to negate the investment in OR over a data layer with optimized processing based on individual scenarios.  Abstractions leak, and abstracting sets to objects or tables just hasn't been solved yet.  I won't say which side of the discussion the CLR team guys came down on, but the conversation itself was fantasic, especially given Jason Zanders' insight as one of the original team members of ODBC at Microsoft.

Sitting through several of the presentations, I thought I had seen quite a bit of this material before based on presentations that I have seen at events like the MVP summit and our DPE airlift.  I was wrong.  The value wasn't the PowerPoint and the introduction of the feature, the value was having the guy responsible for a feature tell you how it came about, what considerations there were behind it.  Here are just some of the things that I noted.

• Q: Whidbey has been over 2 years in the baking... what has the CLR team been working on?  TryParse and SecureString couldn't possibly have taken that long to write.
• A: The majority of the time was spent supporting 64 bit.  Yep, .NET 2.0 supports 64 bit processors even for Windows Forms.  Visual Studio itself is a 32-bit application, but you can write assemblies that are deployed to 64 bit machines and they just run.  There was a lot of work getting details you wouldn't have considered to work with 64 bit, supporting a strong appcompat story, increasing performance, and coordinating the efforts of over 1500 developers and testers together.  This doesn't include managers, marketing people, and other people involved in tasks other than directly coding.  In effect, there were more people working on Whidbey than there were people involved in the first space shuttle launch.

• Q: Why isn't there a SecureString overload for System.Data.SqlClient.SqlConnection.Open?
• A:  The problem isn't providing the overload in the API, the real problem is passing that secure string across the wire so that the database will natively understand without sending the password as clear text.  In other words, you fill out a text box control as text, that is put into a SecureString, passed into the Connection object... which would then pulled out of the connection, serialized to a string, and sent over the wire.  The bigger win wouldn't be just having SecureString overloads in the Connection object, but rather a SecureString that could be passed over the wire and understood by the data provider. In the meantime, there is little value in providing the SecureString that will automatically be serialized to the wire to the database.  The string's gonna live in clear text somewhere still.

• Q: How do you decide to introduce new classes?  There are a ton of classes in the FCL and BCL!
• A: Brad Abrams described a meeting where someone wants to introduce a new type to handle a problem.  As soon as someone wants to introduce a type, they write on the whiteboard, "OK... you have -100 points.  Tell me what this type will do."  "Oh wow, this type is going to do (blah blah blah)".  "Cool feature!  That's worth 40 points.  You're now down to -60.  What else?"  "Hmm... it will be reusable in this way and developers can do this with it."  "Neat!  10 points.  What else?  Nothing?  OK... that's a total of -50, so looks like it's not worth it.  Next item on the list!"  That was a kind of sarcastic way of showing that classes are not modified or introduced easily.  The goal is for high-value, low-impact modifications that solve common problems, like adding TryParse to intrinsic value types.

• Q:  Does the CLR team spend a lot of time traveling?
• A:  Not really.  I asked Brad Abrams about this, expecting a long list of visits to various conferences, but he said he goes to maybe 1 or 2 events per year, like TechEd or PDC.  Getting them on a road trip to Atlanta was a huge opportunity!

• Q: What's the real difference between the SSCLI (code-named "Rotor") and the CLR?
• A:  The commercial JIT and GC.  There are implementations in the SSCLI, but not near what you find in the CLR.

• Q: How does the CLR manage multiple processors?
• A: There are multiple garbage collectors with processor affinity.  Given 32 processors, there would be 32 GCs.  The CLR would manage individual collections as well as inter-CPU collections.  I'd like to see a blog from Jason Zander on this, having heard him explain it twice I am not sure that I can reiterate the concept still.  He explained the optimizations down to taking advantage of L2 cache... admittedly, I have been focusing on line of business applications for entirely too long.  The fact that I have to go back and look up concepts is the kick in the pants, and for that the CLR visit was more than worth it for me.

• Q: Does the garbage collector compact memory, and how?
• A: The GC allocates new objects on gen 0, and it moves the items from gen 0 to gen 1 in a promotion and compacts the memory in the process.  When it does a sweep of gen 0, it will also compact the memory.

• Q:  Why are some lines in the CLR Profiler wider than others? 
• A:  Wider means more allocations.  The wideness of a line gives an indication of how often an object is instantiated relative to other objects represented.  In simple terms, wider is worse.  Read my post from the other night... Claudio just simply rocks.

• Q:  Should you consider using NGEN or not?
• A: NGEN on the server (as in ASP.NET) doesn't make a whole lot of sense.  However, NGEN for a winform client is typically a win.  The issue becomes deployment, as you have to do NGEN on the client, typically as part of the installation.  You can optionally do some optimization testing, like NGEN two test scenarios and comparing the profile performance using the profiling APIs, all within the installation script.  Based on the performance of the NGEN image versus the JIT'd image, you could determine if NGEN will be a win for your application. 

Here are some of the blog postings that I have found so far, if I missed your blog please let me know!

• John Ritsema
• Brenton House
• Brendon Schwartz
• Matt Ranlett
• Michael Earls (priceless)
• Tobin Titus
• Jerry Dennany
• Joseph DeCarlo