Partilhar via

The .NET Vision (aka: the big picture): what are we working towards? [Kit George]

  • Artigo

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 https://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.

At least.

Comments

  • Anonymous
    March 16, 2005
    The comment has been removed
  • Anonymous
    March 16, 2005
    Of course, I haven't answered the question in the terms in which it was originally couched - which was mainly performance-related. And my suggestions are probably outside of the remit of the BCL team. But what I'm saying is that, with regards to takeup of managed code, the size of the redist. and the reverse compilation issue are what hinder all the people I've spoken to - not performance.

    As a writer of .NET applications, I personally would love to be able to write a beautiful piece of shareware like TextPad, have it be a <2Mb download, and not have to fork out $800 for Demeanor in order to protect my code. But I will (probably) buy Demeanor, because I want protection as much as anyone, although sometimes I think that I'm being a bit silly.
  • Anonymous
    March 17, 2005
    Tips
  • Anonymous
    March 17, 2005
    Mike Sampson from the VB team has written about a bootstrapper to help install the CLR lazily on your clients' machine.


    You can read about it here on his blog:
    http://blogs.msdn.com/misampso/archive/2004/03/11/88402.aspx
  • Anonymous
    March 19, 2005
    The comment has been removed
  • Anonymous
    March 21, 2005
    Tips
  • Anonymous
    March 21, 2005
    We're shipping managed apps. Our biggest complaint is related to startup time of a winforms app. We have gone back to using splash screens even on a 3 GHz HT pentium. The redist hasn't been too much of an issue although we were very disappointed that XP SP2 didn't just install .NET 1.1 redist. :-) We've also found some bugs on Win98 that don't show up on NT-based systems.
  • Anonymous
    March 21, 2005
    Oh one other big complaint about managed apps is the lack of support for post-mortem debugging. We send minidump error reports home for analysis on our unmanaged apps. We have never been able to get good minidumps from a managed app. This really bites. The best we can do is send back the exceptions and their respective stack traces, loaded module info, running thread info, etc but no local var/parameter values.