In response to the query for input on what to blog about today, David asked the following question:
“I want to know the big picture on things. What is the vision here? The end game?”
This is one of those questions where you’ll get a slightly different question depending on who you talk to of course. So I’m gonna imagine myself in a couple of different pairs of shoes for a second.
Let’s imagine I’m on the CLR performance team. They would point out that our whidbey focus has been to a) improve startup time and b) improve working set. The former is because we’ve had a lot of (justified) complaints, so it’s obvious we should do something about it. The latter is more interesting from a ‘what’s the big picture’ scenario. We believe there’s significant wins in making NGen’d images with as much shareable memory as possible. In V1.1, the amount of shareable memory in an image was pretty poor (roughly 15-25%). In Whidbey, we’ve done a boatload of work, and we’ve made that 75%-85%, a remarkable increase.
Now why is this important to us? First and foremost, our vision for .NET is to have performance characteristics similar to unmanaged code. We’re not joking. There’s work to do, and we know it, but we’ve got our guns on a specific target, and we know we can get there. In getting there, one of the key steps is going to be getting as many managed dependencies as we can (that is, as many folks building on top of managed code as possible). This gives us more data, more knowledge about the variety of apps that can be built using our product, and the different performance scnearios we need to be aware of, and optimize for. One of the key scenarios we’re gonna have to bite off in the near future is how to make sure we’re ready for OS’s to take dependencies on us. To do that, we have to be meeting their performance goals ,of which, shareable working set is one of the primary critical issues. And at that point, we’ll really be starting to achieve our broader objective, of making .NET the managed coding platform of choice.
In both these cases, we’re asking a fundamental question of customers (external in the first case, internal as it turns out, in the second). ‘What is it that’s preventing, or limiting you from using managed code?’ Once we have the answer, we take the feedback, and respond by addressing them head on, no matter how long-term the solution.
Now let’s step to the side, and imagine I’m working on the CLR hosting team. The hosting team’s key customer was of course ‘Yukon’, Microsoft’s next version of Sql Server. The CLR hosting team has a very real customer who have rigorous demands of the CLR in terms of capabilities, performance, and above all, reliability. After all, we want to be able to ensure that user managed code in Sql Server can run without jeopardizing the stability of the database server. We’ve done just heaps of testing, and taken zillions of bug fixes with this in mind, to ensure that we can achieve our goal not only for SQL Server but for any host that has similar requirements, and by doing this have a successful relationship with Sql Server (note: from a CLR perspective, it’s great to have a key customer like this. But more importantly, we want to make sure that the capability to host the CLR is a very real feature. The absolute best way to do this is to have someone who is depending on delivery of that feature. In other words, having a concrete, demanding customer makes sure we get a good hosting story for everyone else).
Now the broad objective here of course, is to overcome boundaries which would have prevented managed code being the code of choice. If we hadn’t been able to have been hosted, then in all likelihood, Sql would have not been interested in utilizing .NET. In other words, the initial question was ‘what needs to happen for you to utilize and expose .NET?’. And once we had the answer, we simply ripped into the problem, and addressed it.
I’ve given two examples, but I would assert to you that wherever you go in the .NET team right now, either within the CLR, or within other logical groups, the underlying objective is the same. We want to build a product that is your primary coding choice. Not an alternative. Not ‘a nice idea’. Your platform of choice. It turns out that right here, right now, we have a lot of big meaty issues to solve and therefore, you’re hearing about some of the broad initiatives (performance, hosting, servicing, etc.). But in two years, the question will be the same: ‘what do YOU need, in order to either a) move to .NET, or b) make .NET the best experience for coding there is’. And we’ll respond to that.
And now, let’s come back to the BCL. Is our objective the same? It is entirely aligned with the above goals. We have specific sub-goals. For example, we want to ensure that we avoid duplication throughout the framework, we want to ensure we resolve the top requests from external customers, and we want to support internal teams to ensure their goals are met. But at the end of the day, each of those wrap up into one driving need: to offer you the best coding experience there is. We want it to be productive (a critical focus), we want to enable the writing of performant, reliable code, we want a secure environment, we want competitive parity… we want it all. We want the answer to the (example) question of ‘my boss just asked me what platform we should use to design this competitive website: what should I suggest?’ to be so obvious because across the board, we’re the leader.
I would suggest that http://www.osnews.com/story.php?news_id=9441&page=4 is an interesting read in this space as well: it looks a little broader than I do, and also points out issues along the way.
So the features you see in the BCL are steps in that direction: making this the best programming platform there is. This is why your feedback is so important to us. Because at the end of the day, if you think there’s something about .NET that’s unperformant, unreliable, insecure, missing (‘why do I have to PInvoke to do <x>?’), or otherwise deficient, we want to know.
That’ll be the same for the next version too.