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.


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 ...



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.


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!