Rico Mariani's Performance Tidbits

CLR Performance Questionnaire

Vance Morrison posted an interesting opportunity for you to give feedback directly to the CLR perf team on your managed code performance issues.  I encourage you to participate:

If you use managed code, and you care about performance, then we want to hear from you.

We have not yet shipped the next version (what we call Version 4) of the .NET Runtime, however we are 'locked down' enough that at least a few of us on the runtime team are preparing for the version after that (as yet unnamed).   As part of that planning exercise we want YOUR input.    The .NET Performance team wants to know what your 'performance pain points' (is it startup, some throughput scenario, ASP.NET client etc), so we can address your most important issues.

To submit your feedback simply go to the site http://dotnetfxperf2009.questionpro.com/ and fill out the form.   We tried to keep it short and 'low overhead' (we are the performance team after all) .     

Visual Studio: Why is there no 64 bit version? (yet)

Disclaimer: This is yet another of my trademarked "approximately correct" discussions

 From time to time customers or partners ask me about our plans to create a 64 bit version of Visual Studio. When is it coming? Why aren’t we making it a priority? Haven’t we noticed that 64 bit PC’s are very popular? Things like that. We just had an internal discussion about “the 64 bit issue” and so I thought I would elaborate a bit on that discussion for the blog-o-sphere.

So why not 64 bit right away?

Well, there are several concerns with such an endeavor.

First, from a performance perspective the pointers get larger, so data structures get larger, and the processor cache stays the same size. That basically results in a raw speed hit (your mileage may vary).  So you start in a hole and you have to dig yourself out of that hole by using the extra memory above 4G to your advantage.  In Visual Studio this can happen in some large solutions but I think a preferable thing to do is to just use less memory in the first place.  Many of VS’s algorithms are amenable to this.  Here’s an old article that discusses the performance issues at some length: http://blogs.msdn.com/joshwil/archive/2006/07/18/670090.aspx

Secondly, from a cost perspective, probably the shortest path to porting Visual Studio to 64 bit is to port most of it to managed code incrementally and then port the rest.  The cost of a full port of that much native code is going to be quite high and of course all known extensions would break and we’d basically have to create a 64 bit ecosystem pretty much like you do for drivers.  Ouch.

[Clarification 6/11/09: The issue is this:  If all you wanted to do was move the code to 64 bit then yes the shortest path is to do a direct port.  But that’s never the case.  In practice porting has an opportunity cost, it competes with other desires.  So what happens is more like this:  you get teams that have C++ code written for 32 bits and they say “I want to write feature X, if I port to managed I can do feature X plus other things more easily, that seems like a good investment” so they go to managed code for other reasons.  But now they also have a path to 64 bit.  What’s happening in practice is that more and more of the Visual Studio is becoming managed for reasons unrelated to bitness. Hence a sort of net-hybrid porting strategy over time.]

So, all things considered, my feeling is that the best place to run VS for this generation is in the 32 bit emulation mode of a 64 bit operating system; this doubles your available address space without taking the data-space hit and it gives you extra benefits associated with that 64 bit OS.  More on those benefits later.

Having said that, I know there are customers that would benefit from a 64 bit version but I actually think that amount of effort would be better spent in reducing the memory footprint of the IDE’s existing structures rather than doing a port.  There are many tradeoffs here and  the opportunity cost of the port is high.

Is it expensive because the code is old and of poor quality?

It’s not really about the quality of the code – a lot of it is only a few releases old – as it is the amount of code involved.  Visual Studio is huge and most of its packages wouldn’t benefit from 64 bit addressing but nearly all of it would benefit from using more lazy algorithms – the tendency to load too much about the current solution is a general problem which results in slowness even when there is enough memory to do the necessary work.  Adding more memory to facilitate doing even more work that we shouldn’t be doing in the first place tends to incent the wrong behavior.  I want to load less, not more.

Doesn’t being a 64 bit application save you all kinds of page faults and so forth?

A 64 bit address space for the process isn’t going to help you with page faults except in maybe indirect ways, and it will definitely hurt you in direct ways because your data is bigger.  In contrast a 64 bit operating system could help you a lot!  If you’re running as a 32 bit app on a 64 bit OS then you get all of the 4G address space and all of that could be backed by physical memory (if you have the RAM) even without you using 64 bit pointers yourself.   You’ll see potentially huge improvements related to the size of the disk cache (not in your address space) and the fact that your working set won’t need to be eroded in favor of other processes as much.  Transient components and data (like C++ compilers and their big .pch files) stay cached  in physical memory, but not in your address space.  32 bit processes accrue all these benefits just as surely as 64 bit ones.

In fact, the only direct benefit you get from having more address space for your process is that you can allocate more total memory, but if we’re talking about scenarios that already fit in 4G then making the pointers bigger could cause them to not fit and certainly will make them take more memory, never less.  If you don’t have abundant memory that growth might make you page, and even if you do have the memory it will certainly make you miss the cache more often.  Remember the cache size does not grow in 64 bit mode but your data structures do.  Where you might get savings is if the bigger address space allowed you to have less fragmentation and more sharing.  But Vista+ auto-relocates images efficiently anyway for other reasons so this is less of a win.  You might also get benefits if the 64 bit instruction set is especially good for your application (e.g. if you do a ton of 64 bit math)

So, the only way you’re going to see serious benefits is if you have scenarios that simply will not fit into 4G at all.  But, in Visual Studio anyway, when we don’t fit into 4G of memory I have never once found myself thinking “wow, System X needs more address space” I always think “wow, System X needs to go on a diet.”

Your mileage may vary and you can of course imagine certain VS packages (such as a hypothetical data analytics debugging system) that might require staggering amounts of memory but those should be handled as special cases. And it is possible for us to do a hybrid plan with including some 64 bit slave processes. 

I do think we might seem less cool because we’re 32 bit only but I think the right way to fight that battle is with good information, and a great product.

Then why did Office make the decision to go 64 bit?

This section is entirely recreational speculation because I didn’t ask them (though frankly I should). But I think I can guess why. Maybe a kind reader can tell me how wrong I am :)

First, some of the hardest porting issues aren’t about getting the code to run properly but are about making sure that the file formats the new code generates remain compatible with previous (and future) versions of those formats. Remember, the ported code now thinks it has 64 bit offsets in some data structures.  That compatibility could be expensive to achieve because these things find their way into subtle places – potentially any binary file format could have pointer-size issues. However, Office already did a pass on all its file formats to standardize them on compressed XML, so they cannot possibly have embedded pointers anymore. That’s a nice cost saver on the road to 64 bit products.

Secondly, on the benefit side, there are customers out there that would love to load enormous datasets into Excel or Access and process them interactively. Now in Visual Studio I can look you in the face and say “even if your solution has more than 4G of files I shouldn’t have to load it all for you to build and refactor it” but that’s a much harder argument to make for say Excel.

In Visual Studio if you needed to do a new feature like debugging of a giant analytics system that used a lot of memory I would say “make that analytics debugging package 64 bit, the rest can stay the way they are” but porting say half of Excel to 64 bits isn’t exactly practical.

So the Office folks have different motivations and costs and therefore came to different conclusions -- the above are just my personal uninformed guesses as to why that might be the case.

One thing is for sure though: I definitely think that the benefits of the 64 bit operating system are huge for everyone. Even if it was nothing more than using all that extra memory as a giant disk cache, just that can be fabulous, and you get a lot more than that!

Visual Studio 2010 Performance Part 2: Text Editor

Part 1 of this series talked about the startup problems we face.  In Part 2, I want to talk about the editor.

Many people have reported that editing with the new editor is slower. I’ve experienced the same thing myself so I certainly do not want to accuse people of hallucinating but I thought it might be interesting to understand why that might happen, especially since this new editor is supposed to be better than the old.

Why is this editor better and how is it better?

I’m glad you asked :)

It’s actually better in pretty much every editing way. The data structures associated with this new editor do not require complex locking algorithms for access, it delivers logical “micro-snapshots” of the editor buffer which do not change – it is a copy of the buffer at an instant in time. This is a fantastic situation if you are, for instance, a background compiler. Previously to get consistent snapshots the entire buffer had to be copied, potentially on every keystroke!

And if that’s not enough, there’s a lot more. Another big tax on the editor is region management. Regions are used to track everything from bookmarks to breakpoints – and more. Those squiggles you see, those are all regions and there can be thousands of them. That is far beyond what the original editor design intended and those algorithms were starting to degenerate to quadratic behavior. You can see that yourself by noting that simply scrolling around at the end of large files in the old editor tended to get slower.

Those are just two areas, but generally where the old editor had quadratic performance we were able to improve things to linear and in some places we were able to do even less work by being more careful about processing only visible segments of the text buffer. All goodness.

So why is the thing slower if it’s so much better?

Well let me elaborate a little more, but before I answer that directly, first let me tell you what things are almost certainly not the problem.

Not the problem #1: WPF

With the exception of some cases where we found that remoting WPF primitives over terminal server connections was slow, generally the WPF system is more than capable of keeping up with the editor. If you are seeing sluggish typing WPF is almost certainly not to blame.

Not the problem #2: Editor Primitive Operations.

The basic insert primitives are blazing fast, as low as a few microseconds even in very large files. If you’re seeing a problem, the chances that the text buffer is letting you down are slim to none.

Ok, so, if it’s not those things, what is it? There’s two good bets.

Compatibility Shims

The new editor is managed, and it has its own brand new managed interface. You can call it directly. However, there is lots of existing code that knows how to talk to the OLD editor and the old editor had a COM interface with its own particular API. We didn’t want to port all of the editor related code to the new editor’s managed interfaces – for several reasons but perhaps the most important is that there’s just so much of it. So we created a compatibility layer – shims – that allow old callers to use the new editor. That’s also important for our partners out there. That’s all fine and well but of course that means you’re going to be forced to use COM-interop where there was none before and of course those shims have to emulate the old editors behavior even when that wasn’t exactly the fastest choice in the west.

So sometimes improving editor responsiveness has meant converting more code to the direct interface and thereby avoiding the shims. The trick here is to make sure you convert the code that needs converting rather than going crazy trying to convert all of it in one go.

OK but who are all these users? What are we talking about here?

That brings us to the second point.

Event Listeners

Another reason why the editor can get bogged down is that various clients can register for notifications of interesting events. This is actually very popular (understatement) and important things like the language’s intellisense services want to be notified of various things going on in the buffer. Now it turns out that the actual editing primitives are so fast that the bulk of the cost of doing edits is actually in these various event processors. Sometimes because they are using shims, sometimes just because they are being over-aggressive in subscribing to things. Sometimes because they have their own personal problems that are only incidentally related to editing.

One way that you can see the difference in the root cause of editing yourself is to try your editing operations in a file named ‘foo.txt’ rather than ‘foo.cs’ or ‘foo.vb’ or whatever the case may be. This will disable many of the event listeners and give you a truer feel for what the editor itself is doing. Even that isn’t perfect because of course there are still listeners for bookmarks, and other kinds of things that are applicable to even plain text files.

What are we doing about it?

Well I think I’ve already alluded to it. Make better use of the underlying editor primitives. Move more things off the shims where the cost is high. Reduce the cost and number of listeners generally. And of course make sure that our text and region management primitives stay nice and fast.

What can you do?

If you see the editor behaving dumbly, enter bugs. They really help!

Visual Studio 2010 Performance Part 1: Startup

I want to start by thanking everyone that has commented on the Beta (by posting their thoughts here or elsewhere) for doing so. Please keep those comments coming! They have a great impact on the senior leadership here and they are excellent rallying points for all the teams. They really do make a difference!

Jason has come right out and said he’s tapped me to work basically full-time on performance work for Visual Studio until we’re done; that’s understating the situation if that’s possible. I think I had already tapped myself before he tapped me and at this point I’m a bit of a lightning rod for performance issues in the product. I think that’s a good thing. :)

Just like I did back when I was writing about performance problems for the CLR I’m going to talk about things as candidly as possible. Including the bad parts.  While I do that I want you to keep in mind that I write the truth as I see it and I often have to write what I like to called “approximately correct” articles, mostly in the interest of brevity; being more than approximately correct causes the word count to skyrocket. I won’t keep reminding you that I’m doing this but it’s been a while so I thought maybe a refresher would be good.

Lastly, I try to use affirmative language about what I’m doing or what I think the teams are doing but I generally avoid making promises even when any idiot could see that we would be colossally stupid to do other than what I am discussing or perhaps what one of my readers has suggested. I avoid it because there are many teams involved, with many choices at hand, and many opportunities for things to go badly despite the best laid plans. So I just try not to go there. I’m sorry about that.

OK enough disclaimers already.

This is, what I hope is the first in a series of articles about performance related happenings in Visual Studio. I hope you find them helpful and interesting. I’m going to start at the start – and that’s Visual Studio startup.

I’ve actually talked about Startup several times over the last few years. That’s because I want people to understand that of all the things that are going to get better, startup is not one of them. Yup, that’s right; I gave up at the start. No kidding. No pretending. It’s going to start slower. Sorry.

But wait; don’t give up on me yet!

We decided to make some investments in better display technology in this release and for the future; that meant loading WPF at startup. We decided to have a superior extensibility model for our future and that meant MEF at startup. And in general we went from having no managed code at all at startup to having a LOT of managed code at startup. That stuff isn’t free, and nobody knows it better than me. [I rhymed]

In some cases I’ve seen as much as 75% of our time in current startup scenarios actually in clr.dll – incredible isn’t it? In VS2008 that was 0%! But even though that’s technically true, it’s also a bit of a lie…

In VS2008 you could start the IDE without bringing in the managed stack and you could avoid allocating say the GC heaps and whatnot but it’s an illusion. For the most part, if you did anything real you would find that you had paid that cost very shortly after startup and almost certainly before you were “Ready to Work.” That experience is the one that I wanted teams to focus on in this release: don’t prioritize start to empty, prioritize start to ready.

Now in start to ready we are in much better shape. There were many, what shall I call them, hmm, known weaknesses? There were known weaknesses in the startup path from initial boot, to opening your solution, to opening an editor. I’ve talked about many of these in the past. Consumption in the project system and language systems was high. Editor related algorithms were costly, quadratic complexity or worse in some important cases. That means there is opportunity there. So we keep fighting to create an overall experience that you’ll find better, one that will make you more productive, even though we’re giving ground on some parts of the experience.

Now if you think we’re going to open a small foo.txt file as fast as say notepad… well… I’m sorry, we’re not going to do that. We never had a chance. Other editors are making other kinds of tradeoffs and are much better positioned to give a great experience in that case. But if you want to open say a medium sized solution now we’ve got a fighting chance to offer real advantages.

Now maybe that sounds great, or maybe it doesn’t, but in any case the trouble with focusing on end-to-end productivity is that even if you do make the “on average” experience better you still run the risk of having some painful parts be worse than they used to be and those parts just totally ruin the experience for customers. We’re trying to be mindful of that. Take for instance our friend the Add References Dialog, I don’t think anyone is thinking about how “on average the product is faster” when they are waiting for that thing to come up.  I’m sure not.

So this article is supposed to be about Startup, what are we doing to make it better? Well, there are some very specific things that we think are going to help. These ones represent maybe 25% of the total cost of startup (to empty) in the beta build.

• We use WPF toolbars and the toolbar layout code in the beta is naïve. That needs to get better (I like what I see so far)
• WPF does drawing in the background with a render thread; that thread sometimes has to synchronize with the main UI thread. Some of those look like they can be removed.
• The way we create the toolbars is more complicated than it needs to be. We can get the exact same result using fewer UIElements with some style and code changes
• We have a hot list of methods in the CLR that are important in our startup, we’re hoping some of those can be improved, and also that those improvements aren’t unique to Visual Studio
• A classic thing that happens in every Visual Studio release is that we go through a period where we have bunches of code (often VS packages) that are getting loaded at startup that to not need to get loaded at startup. We’re making a list and checking it twice.

The best thing about most of these changes is that they actually help many scenarios (e.g. almost every time we change modes) not just startup.

These things will help Start to Empty to be as good as it can be.  I’m going to talk about Start to Ready more in a later posting.

Visual Studio 10 -- Your Performance Feedback plus Beta 1

At Microsoft you can't say you're excited about anything you have to say that you're "super excited".  I don't know why that's just the way it is.  So, I'm happy to say that I'm super excited about the release of Beta 1 and I encourage you all to visit Jason's blog (again) to see screen-shots and get the download info.  And more importantly to actually try it out and give us feedback.  Your feedback so far has made a big difference and it will continue to do so, if only because it gives me ammunition with which to beat up -- err, I mean, educate -- executives here in DevDiv :)

Right now we're at a stage where it's crucial to lock in the gains we have and make sure everything we do is only making things better.  That means detecting any performance regressions builds, day to day, is paramount.  Now I have some general advice about that, I've been trying to teach for year that consumption metrics are very important and often a better way to track performance even though they aren't directly what your customers care about -- this old article discussed that a bit with regard to memory use.  For regression detection I think it's even more important to focus on consumption rather than elapsed time.  I was trying to explain this yesterday and I came up with this pithy quote:

"Trying to control your performance by measuring only elapsed time is kind of like trying to control your weight by measuring how much time you spend eating."

It's -- dare I say it -- super-important to use a variety of metrics and watch your overall consumption because too many extraneous, impossible to control, variables affect elapsed time run-to-run.

Now moving on to some feedback, I first wanted to thank everyone that wrote in response to my last posting and encourage you to keep giving feedback.  There were a few common themes that I wanted to discuss in detail.

Add/Remove References Dialog

I've personally made a pitch to make this better and I expect to see it getting attention.  At the very least I want the default tab changed to be a faster one.  This dialog is universally despised and got more negative comments than any other feature.

Unit Tests, especially batch runs

That team is looking at larger run cases and trying to optimize the amount of data gathered versus the run speed.  Hope to see some nice gains there.

General Typing speed (C#, VB, C++)

I've been looking at that scenario personally and with a lot of help from our languages team.  There are many factors that affect speed, not the least of which is the language service that provides intellisense but there are other important factors like the raw speed of the new editor, the amount of outlining, etc..    We've made big improvements here since the PDC but we're still not happy with it so we're pushing for even more gains before we ship.

"Cat" commented that "I'd hazard that partial class support was added to C# just because of this problem."  I can assure you that that was not the case.  Partial classes were added for several reasons but I would say the main one was to allow better separation of designer generated code vs. human generated code.

Silverlight and WPF tooling

Some things are already better because WPF is loaded first but other things have suffered because there were many changes in that tool suite and it's still in need of performance work.  I think you'll find Beta1 is better than the PDC but I expect you'll still find some areas wanting.  Typing speed in XAML files was something that we were especially wanting to look at.

Help

I really wish we could be showing you more of this in the beta it was so close to being ready but the internal version just wasn't quite there.   We've totally overhauled how it works, the core storage is a much simpler standards-based solution, the reader is much simplified, the first load should be vastly faster, installing new help and getting updates will be vastly faster.  There's a bit of information on April's blog and in particular you can try out the lo-band version of online help (which I think is a lot closer to what our final look will be).  I've been very involved in this effort and I'm especially looking forward to getting the new help technology into more people's hands.

Copy Local

Patrick brought up an opportunity to improve Copy Local based on his experience.  I'm hoping we can move that solution to use NTFS hard links when they are available to provide that functionality without moving so many bits.  I noticed the same activity in some of our test cases -- the problem is of course not unique to NUnit.

WPF Optimizations

Personally I'm focused on WPF changes that will help Visual Studio -- like for instance improvements in how Toolbars are arranged, and general synchronization between the UI thread and the rendering thread.  Some of this work translates to gains that are helpful universally, some not so much.  But I am encouraging the WPF team to read this posting and that should help too.

Solution/Project management

Lots of work is happening in this space.  Customers sometimes have huge solutions and they can't afford to wait for us to load everything before they are allowed to start working.  I'm actively driving improvements in that area. I wish I could promise more but, I'm not especially merciful, I can promise that :)

Specific Bugs

There were several bug reports already in the feedback, I will do my best to get the right people to look at this stuff.  A lot of times all I can do is shrug -- it's a big product, I know a lot of it but, even after 20 years, I don't know it all.

I'm sorry if I didn't respond to your particular comment, I did read every word but this posting is already too long.

Visual Studio -- working on performance

Jason has a new posting on the progress of Visual Studio and I wanted to chime in myself.  Some people have been wondering what I’ve been up to… I think you’ll be happy to hear that about 2 months ago I put down a bunch of my long term planning responsibilities so that I could work on Visual Studio performance directly.  Woo hoo!

So performance work: what kind of work?  Well the most important thing I’ve been doing is helping people in VS to understand where the problems are, and how to make directed improvements that get locked in.  I’ve been doing lots of training, I’ve been creating custom analysis tools for studying VS performance problems, and I’ve also been yelling at a lot of people and just generally making all kinds of friends in my division.  :)

During these last weeks we’ve made a lot of progress, I’m sure you’re going to feel the product is a lot snappier than the builds we provided at the PDC.  But of course I’m never satisfied – there are even more wins coming later.  I worked with many different teams to help us with our startup, with UI transitions, with memory usage, with threading issues – especially with how WPF and our main thread synchronize.  This very morning I’m busy reviewing goals for every major group in Visual Studio and we’re working hard to create a great experience.  I’m especially happy with the changes that will benefit many applications (like some of the ones that are finding their way into WPF, or interop)

So, especially for the next big push before release, performance will be a very high priority for Visual Studio – I’m going to be very pleasantly busy.  

What does this all mean to you?  My blog is now a great place to give your feedback, especially on the Beta when it comes out.  Tell me what is hurting you the most, many people will be watching, including me, and we still have time to get attention on key problems.  I'd love to hear about it.

Visual Studio Today, Tomorrow and Beyond

Looks like it's interview season for me just now.  Here's another piece on Visual Studio directions, based on questions from Channel 9 readers.

Visual Studio Today, Tomorrow, and Beyond

Thanks to Charles for having me on, it's always fun :)

Performance Advice, Southern Style

While I was at PDC2008 I was introduced to Keith and Woody -- pretty soon there was a microphone in front of me and we were doing a podcast.  Now I already liked these guys but when they used a picture of me from about 1998 I really liked them a lot more.  I wish I still looked like that :).

And the interview was pretty fun too. ;)

Keith, Woody, thanks for having me.

You guys can check it out here:

 http://deepfriedbytes.com/podcast/episode-21-talking-performance-with-performance-preacher-rico-mariani/

Visual Studio Futures -- Extensibility Video

This is a brief interview from our most recent VSX conference.

Paramesh Vaidyanathan, Principal Product Unit Manager, and Rico Mariani, Architect for the Visual Studio Platform team shares their ideas and long term goals for Visual Studio.

You'll hear about the new changes coming to Visual Studio 2010 like the WPF-based editor, the new Visual Studio extensibility architecture and the key areas the team is looking to address beyond Visual Studio 2010.

Check it out and you'll see my response to this excellent and provocative comment by "florindonot"

you people have in-principle OK ideas but you lack the vitality to say NO and to cut to the relevant.
you end up with kilometers of code, which only reinforces what you are able to do today and ends up defining the status quo for everyone else.  this is comfortable (and so it is understandable - there is no contempt) but there are cleaner ways forward.

Visual Studio Dialogue with WPF Performance Emphasis

Lots of great comments on my last posting, I wanted to address the performance concerns especially.  I'm always amazed by the wide variety of opinions :)

First I'd just like to say that I didn't suddenly forget all my performance religion when I took this job and I believe the developer division at large has discovered this :)  I'm trying very hard to drive good goals and culture and I think it makes a difference.  Of course I'm never satisfied but that's par for the course in the world of performance management.

I'm just going to grab a selected set of comments here and try to address them pretty much in order.

The thing that miffs me with WPF is cleartype.  There's not facility whatsoever to turn it off, from what I can tell and have researched, for WPF based applications.  This alone makes me worried to all heck about the future of my favorite IDE (and being a C# developer, this is even more important to me).

Please, please, please let me disable that mess that is cleartype.  For me, it isn't clear, and gives me nearly instant eyestrain and headaches.

I'd hate to be forced to use fonts that don't fit my needs as well just so that I can have some supposed "new and exciting" interface in an arena where I just don't need it.  I'd wager that other developers don't need to be graphically wowed by their IDE either.

[...]

Tuesday, November 18, 2008 7:24 PM by Steven Raybell

The cleartype concern isn't one that I'd heard before I will see what I can do make sure we have good font choices there.  I expect we'll have lots of skinning opportunities.

There is a really important underlying point here.  We're not embracing WPF because we want graphical "WOW" -- that wouldn't be enough of a reason.  What we want is flexibility and extensibility.  For instance, it's because the new editor is WPF based that we can, for reasonably engineering cost, offer the ability to add inline adornments, margins, even "heads up display" style extensions.  These are not just minor little toys or typical editor extensions you could literally change the way you work by extending the editor to include rich display of imbedded or related information.  I expect this to fundamentally change the way people think about code editing... the toy example showing reformatted XML inline with the text plus bug links was just the beginning.  The best part is you won't have to wait for us to do these things -- you want profiler information overlaid on your text?  No problem go do it;  Test coverage?  Hot links to documentation?  Online presence indicators based on email names in comments?  You could do all these things.

Rico,

Great article and great direction to take this excellent product. I love the idea of integrating azure like features. Buddy coding would be great. An integrated iphone like app store for VS extensions would be great for the various extension developers. 

I guess a few questions that tie in:

1. Will the new design of VS allow me, the end-user, to disable a bunch of features (because of the clean extensibility model) to such an extent that VS launches as fast as notepad and acts as fast as it? I know its not such a realistic example but I think it a really admirable goal.

2. Will the new design of VS allow me to better diagnose issues with visual studio. For example if my cpu suddenly jumps to 100% will I be able to find out that component XYZ is responsible, and disable it? I'm thinking something like Google chromes task manager ..

3. You did allude to API simplification on the extensibility side, I think this is fantastic, are you going to have the freedom to break backwards compatibility?     

4. In a tie in question, what improvements are you looking at around profiling and diagnostics, a tool like ants profiler baked in perhaps?

Again, great article and I think you are on the right track.

On a side, fairly insignificant note compared to all the rest. Will you be looking at providing proper support for developing MCML apps in VS.Net? (I'm tired of pushing xml around) I've advocated for quite a while that they should get rid of that technology and replace it with WPF but it seems not to be happening ...

Cheers

Sam

Tuesday, November 18, 2008 9:50 PM by Sam

Lots of different questions here.  Let me pick some of these off, keeping in mind I can't promise feature deliveries but I can tell you what I think about:

• Azure based services are something I think about a lot, we'd be foolish to not include some kind of services angle to our product in this climate
• I love the buddy coding idea, that's another one I think about a lot
• Launching as fast as notepad?  I don't see how I'm ever going to pull of that miracle: editing tiny text files is not really the sweet-spot for the product but slimming down extensions is definitely something I want to do, even if we're not as fast as notepad a diet is never bad thing.  Especially for our isolated shell offering
• More user visibility of what VS is doing internally and management of long running tasks is another thing I think about, it's longer term though
• I am willing to "break some eggs" on the backward compatibility front -- I don't have the same iron-clad burden as say Windows does but neither can we go crazy.  Where we're making changes we have to communicate them clearly and do it for significant benefit.
• We have a profiler in the VSTS product line, many people have asked about putting it in one of the more affordable SKUs.  I guess all I can say there is that it's normal for features to move down in time and this is a popular request.  But I definitely don't make the "which feature goes in which version" decisions.  Sorry :(
• I know basically nothing about MCML applications but I can tell you the long term strategy is that we need sufficient extensibility and separation of concerns that people like the Media Center team do not need to beg us to support their platform -- they should be able to do everything they need with our basic toolkit.  Nothing else really has any chance of working -- there are so many important platforms.

Wow. Rico, I think you're the first person I've talked to in a long time that "gets it".

So many people are on either side of the camp: either the

"go back to VC6 luddites/we don't need no stinkin' gradients" camp

or the

"don't worry about how much resources we consume" camp.

Additionally, you're not saying, "Hey, I've got a brilliant idea. Let's rewrite the damn thing." Instead, you're taking the high road and doing a remodel.

I'm encouraged by what you've written in this post! And I'm really looking forward to Rico's VS2010!

Tuesday, November 18, 2008 11:34 PM by JudahGabriel

Thank you :)  Everything in moderation. 

Moving over to WPF is fine if, and only if, it's not at the expense of *any* end user experience/functionality.

Microsoft is famous for not getting 100% there and then saying "that's as much as we could fit into a v1 release".  Leaving any features that are replaced with WPF with reduced functionality is simply not an option.

If you can't at the very least keep the feature set on par, then it's absolutely not ready to be replaced with WPF.

Remember - developers are a picky and unforgiving lot!

Wednesday, November 19, 2008 6:25 AM by danieldsmith

Not any performance or any functionality?  No I don't think I can promise that.  I'm sure, for instance, that in the smallest cases that we will take a startup performance hit to get things rolling.  But I'm being pretty ruthless about demanding savings in other areas so that overall for medium to large solutions I'm hopeful we can come out ahead.  That's my goal anyway -- I refuse to have the goal be parity.

Remember it's not just about gradients or whatever, it's about a whole new editing experience.  I believe this kind of deep extensibility is unprecedented.

The funny thing is, I think the general concern over WPF performance is perhaps misplaced.  It's not that I'm especially concerned about the ability of WPF to keep up with our displays -- I mean think about it, a typical editor screen-full if it one WPF element for every letter would still only be a few thousand elements, and of course it won't be one per letter.  Importantly, the idea of creating a WPF representation of the entire text document is simply nuts (the document could be many megabytes under totally normal circumstances) so we must create just what we need for a screen-full. Once we do that, do we really think a few thousand glyphs is going to be a problem for that engine? 

But there's more... it's not like the old editor was this flawless creation, it had its limits and design choices too. It's already sluggish on large files and not because of the drawing either.  The region management algorithms for instance (and every little thing you see that's attached to text, from outlining to underlining, is a region) were quadratic in nature. The new editor has much better fundamentals.

So what am I concerned about?  We can't use the new editor API universally, there's just too much code to port, and we have other customers for that API --  so for them and for us we created a shimming layer that exposes the bulk of the old editors interface on the new editor.  But there are places where we have to emulate the old behaviors and those result in the old costs.  That's a much bigger worry for me than WPF per se.  But it is manageable -- after all, if it is really bad in some area we can always convert that to the newer API.

VS10 and WPF is the most exciting thing about VS, ever :), I'm sure WPF will be used for much more than a pretty UI, it will be used for a more functional and dynamic UI. Finally something that gets me over excited about VS10.

Wednesday, November 19, 2008 6:36 AM by Pop Catalin

You betcha :)

Hi Rico,

It's great to see the emphasis on a more reponsible [sic] use of memory. Unfortunately, a lot of developers don't care about memory usage and subsequently end up with applications don't scale.

I agree with the WPF part. Using WPF as the graphics foundation for VS should definetely [sic] warrant a lot of focus for getting the best performance, features and scalability out of that graphics framework.

One thing that VS currently don't do very well is managing really large files (e.g. XML files of 64 or 128 MB). It's just not ideal to check these files for data using the IDE (other editors have better formance [sic] I'm sure, but I'd like to stick with VS).

Don't forget to keep us posted :-)

Wednesday, November 19, 2008 8:22 AM by Anders Borum

Accounting/budgeting use of resources has been a long time drive of mine.  It's the cornerstone of good performance culture, nothing new there I guess.  But more people to convince :)

I know for a fact that the XML language service is getting lots of attention and I believe the new editor will be very helpful there.  I think you'll be very pleased.

I don't care about looks, but I can imagine lots of MS fanboys really need that.

Make VStudio responsive (like VC98 IDE) and scalable and I'll be happy. I don't really think you can achieve that with WPF in the product core. Good luck anyway.

Wednesday, November 19, 2008 9:10 AM by pingpong

I hope you'll be pleased with what we produce.  Certainly I wouldn't be doing this if it was just about incrementally improving the look.  Of course scalability is very high on my list.

IMO UI look is in a lot lower priority.

1. Performance

2. Extensibility

3. Low memory usage

4. Developer productivity

These are important to me.

I believe currently WPF is against #1 and #3.

Thanks,

Wednesday, November 19, 2008 5:15 PM by R.J

I'm sounding like a broken record now, but of course we're not using WPF strictly to get a new look, although that is important too.   Just for comparison, the biggest source of memory usage in the system isn't anywhere near the editor itself -- the combination of language services (compilation+trees for intellisense), project system, and solution system take perhaps 10x the memory that editing does and they have limited visuals.  Ultimately WPF's use of memory (assuming we don't do stupid things) will be a tiny fraction of our overall consumption for large solutions.  Getting the main consumption sources down (by better memory allocation strategies for instance) is a much bigger deal.

You hit it on the right spot. IDE literally dies when working on files with > 5K lines.

Please do something to improve that horrible experience, generations will worship you.

Thursday, November 20, 2008 12:28 PM by Tanveer Badar

The new editor scales much better than the old editor.  But you don't have to worship me :)   If you're feeling very generous make a donation to your favorite charity :) :)

It's great to hear the next release will focus on extensibility and more efficient memory usage.

However, i don't see that much benefit in moving to WPF: "Do you really think GDI is the last word in computer graphics for the next 10 years?"

In all truth, VS2008 isn't really that much ahead of my old Turbo C 2.0 as you would expect from 20 years of constant improvement, but I guess that there will be people who will drool on eye candy.

[...]

The startup is not the only pain point, please also consider shutdown. I typically run 2 or 3 instances of VS, and when I try to close one or more, I have to wait for a long time, until finally I get tired and kill it in ProcessExplorer. This is a common scenario for me and most of my colleagues, and there are many other places when users have to wait because of some seemingly innocuous operation.

And as someone already noted: allow me to turn off everything I don't need, and tweak the environment to the way I prefer to work. That single improvement would make it worthwhile to move to VS2010.

Thursday, November 20, 2008 4:01 PM by zdeslav

I think you're right that we still look a lot like classic IDE systems of the past.  I think we need to change that, there have been lots of improvements in the UX space that we should bring to VS.  But as I've written above, I don't want to do this just to get eye candy.

If you want to know how I feel about shutdown you need go no further than this article -- I'm pretty hard core :)

More use control of components, that's goodness for the roadmap too.

I'm starting to feel like Don Quixote tilting at windmills to get all of this :)

"Do you really think GDI is the last word in computer graphics for the next 10 years?"

My response? "For IDEs? I sure hope so."

Make it fast, make it scale, make it extensible. There's still too much to gain in these areas to be bold about eye candy.

And I know I'm being unfair when I'm dismissing a potential move to WPF as "eye candy", but the bar is very high if you want to create an interface that's radically more usable than what we've already got. Which I hope would be the point of moving to WPF.

IDEs aren't supposed to be wow material in the UI department, so what's with wanting it to be "modern" in the first place? It should mesh well with the OS, but beyond that, anything that doesn't translate to developer productivity gains is, IMO, a waste of human and technical resources.

I do see the benefit to MS for dogfooding their own UI technology in their flagship product, but that's more a service to WPF than it is to VS, and as a backend developer I'm more than slightly biased against it.

Friday, November 21, 2008 4:06 AM by JM

I respectfully disagree with JM, except that clearly we do agree it shouldn't be about eye-candy. 

We used to have real innovations in user experience in the IDE -- pervasive tool tips, like in the debugger, docking windows, high quality customizable toolbars, and other things.  I think we should be blazing trails here too, in ways that are appropriate for a development environment.

Great post Rico, and great video with Paramesh on C9.

If it wasn't for you being on the VS team, the news about WPF in VS10 would have made me weep.

I was *so* glad to see that Anders managed to get a dig in about VS perf not once but *twice* in his PDC talk. 

The current VS is shockingly bad for perf and I reckon 100M developers' hopes are pinned on *you* Rico to get it fixed.   Don't fail us, please!

Friday, November 21, 2008 3:02 PM by willdean

I love you guys.  *cough* no pressure *cough*

I do really appreciate your confidence...

I better not screw this up...

Speed.  100% this is my biggest gripe.  Asp.net solutions that take FOREVER to build and deploy and load, etc.

Do this for me, start filewatcher and then open a VS ASP.NET project.  When you see 1000's of file open requests (duplicates in many cases) you will see the issue.  What about build - dont get me started - there are 10s of 1000s of file open requests, checking and most are duplicates.   The Hard drive is the slowest thing on a computer - so could you guys not figure out to use it as little as possible?

Friday, November 21, 2008 4:02 PM by Wayne

--

I strongly agree with Wayne. The best optimization that can be done is on speed, and most likely through better and fewer file accesses.

Friday, November 21, 2008 5:14 PM by Fabrice

I'm glad someone else mentioned one of the other big four resource usage sources.  And arguably the slowest.  Yes that needs attention too.

Great post and great suggestions in comments. Here's my list (in order of importance)

1) Ability to disable clear-type!  [.. covered elsewhere ..]

2) Performance, performance, performance!

I can live with slow start-up, shut-down, or large memory usage. I really don't need animations or much glitz; I'll take it if it helps though. My #1 complaint with the current version is the ASPX editing (not the designer, I've given up on that a long time ago). It interrupts my flow all the time [...]

However, it needs to be so good that I won't even be able to know that it's WPF based. If you can't get the performance at least to the level of the current editor then please don't even try. Thanks.

P.S. Have I mentioned performance?!

Friday, November 21, 2008 7:33 PM by Peter

I'm getting the message on clear-type options :)

I don't think the WPF-ness of the new editor will help you here but it also has this great composable buffers architecture that should allow significant simplifications in how the ASPX experience works and hopefully that means hourglasses for you.

I like what you said about how it shouldn't matter to you that the new editor is WPF.  I think that's the right model for us.

Rico, your WPF reasoning sounds concise and may be even convincing, but you restrict yourselves down the same old path of "dogfooding new and cool windows technologies".

Why don't you take a shot at a paradigm shift for a change? Why don't you hire 3-4 game developers in your team, experts in 3D, custom UIs and *performance*, and then build a whole new IDE that is NOT a windows application at its core but a DirectX "game"? I have seen mind-blasting UIs from game devs (not in the games themselves but in the dev tools for the games). I am sure you can find a couple of super-highly-talented game devs to add to the picture.

Warm Regards

Monday, November 24, 2008 9:55 AM by Dimitris Staikos

Well I like your way of thinking.  I've been trying to get people to think about creating "game quality UI" but of course we have to do that responsibly -- we don't really *want* to have 75fps in order to use the thing.  But the idea of having those great production values really resonates with me. 

But using DirectX, directly?  Could be issues there -- like terminal server support for instance.  WPF is a pretty good compromise.  Remember, even games use a rendering engine to simplify their programming model.  You can think of WPF as our rendering engine, it helps with the kinds of compositions we want to do.

All I want out of VS2010 is for the RAM usage not to double.  I run a lot of IDE instances (I have 5 copies of VS2008 running now), and everytime I've upgraded to a new version of Visual Studio, I have to double the RAM in my machine.

VS2003 - 1GB

VS2005 - 2GB

VS2008 - 4GB

At the rate this is going, VS2010 is going to require a 64-bit OS.

Grrrr... I'll be a corpse before I let that happen :)

Where's my light-sabre!

What a great note to end on :)

Thank's to everyone who posted and I hope this helps clarify how I think about things.  I really appreciate the high quality comments!

The Visual Studio Tech Roadmap -- Starring Visual Studio 2010

[Dear Readers:I wrote a followup posting  Visual Studio Dialogue with WPF Performance Emphasis based on the comments below and there was a related interview on Channel 9: Visual Studio Futures -- Extensibility Video, I include those links here for easy reference]

Well the time has finally come for me to start writing about my new job in earnest.  My long time readers know that I became Chief Architect of Visual Studio in the summer of 2007 and I've been working on Visual Studio 2010 issues since then.  Well actually, believe it or not, I'm already working on whatever comes after that too but let's not get ahead of ourselves.

So what's the plan for 2010?

Well before I get into that you should know that lots of the things I will be writing about are still under development and while I talk about things I want to see, or wanted to see when these plans were created, that's not the same as them being in the product.  I am the Chief Architect but I'm also *only* the Chief Architect, I don't make the final decisions about what goes in the product, not even combined with the other architects.  Jointly we come up with the long term technology roadmap, it indicates key problems that need to be solved for the long-term health of the product among other things, but these things cannot usually be mapped directly in to features in a particular release.  So, while it's true that I have a significant effect on what we do, it is inadvisable to take any of what I write as some kind of commitment to deliver particular features; rather I talk about examples of things that we might do that are in line with the roadmap.  That's an important distinction and one that is frequently lost by commentators.

Still with me?  I hope so.  OK, the plan.

When we first started looking at our issues for this wave, and even going forward, we established a few major themes that we wanted to work on over the course of the next several releases.  We wanted to make large scale improvements on a long time scale and we didn't want to "go dark" for several years and then release some new development environment that magically solved all our problems -- we opted for a long term plan to "remodel the product."  So, how do we think about that?  Here are the major themes, keeping in mind that I don't want to write a novel :)

Visual Studio Should be Extensible

How can I stand here and tell you that it needs to be more extensible when nearly the whole thing is already an extension?  I mean if you launched Visual Studio with no extensions at all you'd get basically an empty frame with a File Exit menu or something like that.  How can it be not extensible, it's ALL extensions, right?

Well, yes, but... not so fast.  The core of Visual Studio is very extensible but many of our customers do not want to extend the core, they want to extend the extensions.  Now the story gets a lot more complicated.  How do you extend those?  Sometimes you can, sometimes you can't, and there isn't consistency about the mechanism either.  Compounding this difficulty, we universally get requests for a managed extensibility solution -- less COM, more simple managed components.

This calls for a change of strategy.

So to meet these needs we embraced what became known as the Managed Extensibility Framework (MEF) and two major extensibility areas in Visual Studio 2010 import and export according to that standard.  Now of course MEF was just a gleam in our eyes when we started but as you can see from what we're able to show in the PDC bits we've come a long way there.  We've taken major MEF dependencies in both our new Text Editor (more on that below) and in the new C++ project system.

If you've seen demonstration of the new editor then I hope you've been blown away by what you can do with a real fine-grained extensibility model in this space.  Fairly simple components can make pervasive and highly valuable extensions.  This is not your grand-daddies editor.

Our long term plan calls for more MEF extensibility in each release, not a massive rewrite but again, a gradual remodel.

Visual Studio Should be Modern

If you put VS2008 side by side with say VC98 they would certainly look different.  But, even though they are different, could your mom tell you which one was made in 1998?  I'm not 100% sure my mom could tell.  Sorry mom.   OK suppose you put the 1988 IDE side by side with the 1998 IDE.  Could your mom tell?  I'm pretty darn sure she could.

Being modern isn't about just having the latest trendy look and feel.  Though I'd like to have that too.  It's about being able to take advantage of the latest hardware and experience advances.  Can we make use of today's GPUs?  Are we going to be ready for many-core CPUs?  Pervasive high-speed networks?

This may sound like a no-brainer but there is often resistance.  Let me pick my favorite issue for VS2010 -- using WPF pervasively.  Many people, at least initially think I'm nuts to advocate taking that dependency.  "Can you afford it?  What about scenario <X> I heard WPF isn't so good at <X>."  I've been pretty much silencing dissent with the following observation:

"Do you really think GDI is the last word in computer graphics for the next 10 years?"

I certainly don't think so, and, so far, nobody I've asked has been able to answer in the affirmative either.  So we could stick our head in the sand and pretend WPF doesn't exist or we could start investing in the future. 

I know we are bound have some problems with WPF.  We have to fix them, and who better than us?  We've done medium sized WPF applications (e.g. Blend), and now we're going to drive a Flagship Application, maybe the 3rd largest suite in the world (I dunno exactly but it's up there), right down WPF Boulevard and we're going to Make It Work.  It will be great for us, and for WPF itself, and then others can follow with confidence.  There is no real alternative because we can't just sit here on our old UI and then expect to magically have a modern look in 10 years.  And our friends in WPF-land are just as excited about this as I am... maybe more so if that's possible.

There's more we will do.  Some of our code is has deep OLE entanglements because of its STA nature and this prevents us from taking advantage of multiple cores in the way we would like to.  We'll have to start addressing those as well... again, it will come in steps but there is much to do now, some of it invisible, so that we have the technology we need when we need it.

Visual Studio Should be Scalable and Frugal [1]

It's easy to assume that since we're taking a dependency on WPF, that we're planning to do work, for instance, in the editor (a core asset), and in the start page, that VS will necessarily get bigger.  That the new editor, being WPF, must necessarily be slower.

That's defeatist tripe.

The fact of the matter is that the existing VS codebase is far from ideal, and while we will certainly be loading more code at startup that doesn't mean that we can find other wins elsewhere so that on middle to large sized solutions we can pay for the cost WPF.  I know there are areas that can use improvement, we did a lot of work of this ilk in VS2008 and there is still more we can do.  Larger solutions can use upwards of 1G of memory, even a 10% savings there would pay for the cost of loading WPF many times over.

And there's more.

Our existing editor is definitely showing its age.  Many of the key supporting algorithms for tracking regions have very poor (quadratic) performance characteristics and so they slow down massively as file size increases.  These algorithms were fine in the past but as region tracking supports more and more features the size of the files and the number of regions has continued to increase.  In some cases these significantly affect even basic scrolling speed in the old editor.  This doesn't need to be the case, there are other choices for region management with much better scalability.

Additionally, any extender of the old editor can tell you that it did not offer a consistent buffer snapshot model so in cases (like say VB) where we want to do a background compilation, we are forced to copy the entire buffer on every keystroke so that the compiler gets a consistent image. I think we can do a lot better than that.

I did a quick demonstration for my VP last year where I showed a simple MFC application build and debug scenario in VC98 vs. VS2008 -- and don't get me wrong, I think VS2008 made great progress on this front and I think it's a great product, but --- suffice to say that VS2008 used quite a lot more memory to do the same job as VC98.

Yes of course VS2008 can do more than VC98, but seriously, I think there is room to improve here.  Remember I was around for C6.0, I have a long memory :)

Sometimes people tell me we should go to a 64 bit solution to get the scale we need.  I think that's wrong, I think what we need is to use less memory not more memory, I think we have non-lazy algorithms in some key places and we need to address those.  That's what I'm pushing for.  I don't want us take act like we have even more memory -- we might move in the wrong direction if we do that.  But we do need a 64 bit plan and that's something for another posting.

Visual Studio Should be Connected

I'll deal with this one briefly because this posting is already far too long for my taste.

We didn't just invent Windows Azure for the rest of the world, there are many excellent services that a development solution can/should provide/consume.  It doesn't all have to be cloud-based either: Basic peer-to-peer collaboration scenarios are increasingly important, buddy programming, local services, lab scenarios, and so forth.  VS2008 has a fairly limited set of connected offerings, that's something that has to improve as part of our roadmap.  Our Team <*> offerings are already heading down this path and I think there is room in the Pro version for some of this as well... especially in the 10 year time-frame.

Conclusion

Well, this is just a taste of what I've been thinking about.  It's the direction I've been driving for the last year and a half.  Later I'll do a posting on specific initiatives that came out of this, things you are likely to see, some of which I've mentioned above and some which I haven't.  I want to reinforce again that this is not a laundry list of features, this is about describing the kinds of things we wanted to consider and the way we will approach our technology roadmap for many releases.  I hope you'll find it helpful even though, like everything else I write, it's offered "as is, with no warrantee."

Patterns and Practices Performance "PAG"

If you're looking for the blue perf book "Improving .NET Application Performance and Scalability" which used to be a msdn.microsoft.com/perf it's now at

 

http://msdn.microsoft.com/en-us/library/ms998530.aspx

 

That's easy to remember...

Performance by Design at PDC2008!

I'm happy to announce that I will be at PDC2008 (and I will work the booths until I can't speak) but in particular I'll be kicking off this precon event with my longtime colleagues Mark, Joe, and Vance.

Come on out, I'd love to meet some of my readers!

Performance by Design: Using the .NET Framework

Presenters: Mark Friedman, Joe Hellerstein, Rico Mariani, Vance Morrison

The.NET Framework offers developers a dizzying array of design choices for building applications, whether they are client or server-side applications. These choices can greatly impact the performance and scalability of your application. This session highlights best practices in application architecture, testing, tools, and techniques for building responsive and highly scalable applications using the .NET Framework. More than just practical advice, this session focuses on proven techniques for building high quality applications. You will also learn what measurement data is available from the CLR and the OS and will understand how to leverage this data to optimize your application’s performance.

Is Performance a "functional" requirement?

We had an internal thread on this yesterday, maybe I was a little too glib but here is what I had to say about the topic [edited so it can be read standalone]

The original question, “Is performance a functional requirement” is highly unexciting for me.  However the revised question, “What is the best way to capture performance requirements” is profoundly interesting.  It is precisely the (anti-)correlations between attainable functionality and level of responsiveness that sometimes makes for the very best engineering work.  How do you capture all this?  Sometimes pervasively. I would argue that pervasively is in fact the only answer that works in non-trivial cases.  And this is not limited to performance as the quality metric of interest – it applies to any quality that is not going to be trivially achieved.

The nomenclature to me is uninteresting except to the extent that it assists designers and implementers in capturing  and understanding the various kinds of requirements – i.e. I know where to put them, I know where to find them, I know that I got them all, because I am, literally, on a first name basis with all the requirement types. 

I don’t want to trivialize that aspect, but, beyond that, meh, whatever… functional schmuntional, I don’t care what you call it, just do it :)

Linq Compiled Queries Q & A

I did a series of postings on Linq Compiled Queries last year, I recently got some questions on those postings that I thought would be of general interest.

Q1:

Why use the 'new' keyword in this snippet?

var q = from o in nw.Orders
select new {o.everything …};

A:

If you did just :

var q = from o in nw.Orders
select o;

You're getting editable orders. Linq then has to track them in case you change them and want to submit the changes. If you use new effectively you're making a copy of the orders that is not going to be change tracked. That's faster for read only cases. The other thing you can do is mark the query context as read-only and then you get the same effect.  When I wrote that test case, that feature wasn't available yet so I used new to simulate it.

Q2: 

What do you mean when you say that linq will 'Create custom methods that bind the data perfectly' ?

A:

Whenever you use linq to sql to read data from a database it has to do two important things for you. The first is convert your Linq query into SQL. The second is to make a method that takes the stream of data that comes back from the database and converts it into the managed objects you required. That's the data-binding step. Linq creates the necessary methods automatically, and it makes the perfect code for doing this.

Q3:

How did Linq to SQL beat your ADO.Net code for insert times.  Shouldn't a tie be the best possible result?

A:

The SQL I used in my test case was pretty much the standard simplest SQL you would use for such a job. The automatically generated SQL from Linq was better than what I wrote by hand because they had parameterized the insert statements which I never bothered to do. Had I changed my SQL to what they created it would have been a tie. This is kind of like when the C++ compiler finds a machine code pattern that is better than what you would have written doing it by hand because it did something you don't usually bother doing with hand tuned machine code. But you *could* replace what you wrote with what the compiler generated.

Q4:

What are the downsides to precompiled queries?

A:

There is no penalty to precompiling (see Quiz #13). The only way you might lose performance is if you precompile a zillion queries and then hardly use them at all -- you'd be wasting a lot of memory for no good reason. 

But measure :)