bharry's WebLog : Visual Studio

VS 2010 & .NET 4 Public Release Candidate Planned

bharry — Fri, 18 Dec 2009 00:57:00 GMT

I've written extensively in the last few weeks about the feedback we've gotten from our Beta 2. I hope you can tell we've heard your feedback, we are taking it very seriously and are committed to shipping a product that you love. I'm grateful for all of the feedback you've given. I'm also grateful to all of you who have been able to pick up Super-Limited Community Technology Preview (SLCTP) builds.

As we look at the feedback we've gotten and the improvements we've made, we're convinced we need another round of broad feedback. As such we're announcing some changes to the 2010 end game. The driving force is the inclusion of a publicly available, "go-live", supported Release Candidate in February. We believe we'll have the vast majority of the feedback addressed in time for the release candidate and will be looking for another broad round of feedback to ensure it is ready.

We will also be producing an SLCTP3 build in mid January for one more private, non-disclosure agreement, round of validation by those of you who would like to validate that the highest priority issues have been resolved. Given that the RC will only be a few weeks later, I'm not expecting too many people to opt for it, but at a minimum, we'll be updating our internal dogfooders with it to ensure we are ready for the RC.

As part of accomodating this public release candidate, we will be moving the planned launch date back a few weeks.

Thanks ton for all the feedback you've given so far. Please keep it coming and we'll keep addressing it.

Brian

Update on Debugger Perf

bharry — Fri, 18 Dec 2009 00:01:07 GMT

One of the things we got a lot of performance feedback on in Beta 2 was the debugger. We’ve been working hard on it since Beta 2 and it’s looking much better. There was no single thing that was a magic bullet that made everything go faster – but rather a whole lot of small things that together have made a huge difference. Like many of the areas we got feedback on in Beta 2, we decided we were really going to drill on perf on not only make it much better but not stop until it was even clearly better than VS 2008. I’m very proud to say we’ve accomplished that with the debugger now.

We worked specifically to improve time from F5 to first break point, step over and step into time, time to restore responsiveness after stop debugging, interop debugging, disassembly debugging, thread & Intellitrace window repainting and more.

Using the Blend solution as a test case (we’ve used many but this was a good one to highlight issues), we’ve taken some measurements I’d like to share with you. First, I asked for a comparison for stepping in the Blend solution (averaged over many steps) compared to VS 2008. For VS 2008, the time was .72 seconds. For VS 2010, it is now .52 seconds. It was several times slower than that at Beta 2.

To demonstrate graphically the improvements since Beta 2, I have a video, thanks to Steve Carroll. VS 2010 Beta 2 is on the left, VS 2010 (today) is on the right. They are running through the same stepping scenario in the Blend code base. No, the fact that the right one stops changing when the left one has barely gotten started is not a bug – it’s the improvement :)

We’re still not done yet. At this point many of the areas (solution load, Virtual Memory usage, debugger, WPF/Silverlight designer) are better than VS 2008. Others (typing/IntelliSense, some WPF rendering, leaks) have made tremendous progress but aren’t quite where we’d like them yet. And a few others (startup performance, build performance, and some general UI sluggishness) are still building momentum.

We’re making great progress and I’ll continue to keep you posted as we make headway. As always, thanks a ton for your engagement and feedback.

P.S. I apologize for the size of the video. That’s what I got and with all the perf investigations going on, I just didn’t have the time to figure out how to shrink it.

Brian

GamCom Talmia - A very cool process automation tool for TFS

bharry — Wed, 16 Dec 2009 13:11:25 GMT

GamCom have just released a video demo of Talmia, their innovative process workflow tool for Team Foundation Server.

The video shows how an example development process can be implemented so that work items are created and updated automatically along with relevant email alerts, escalation criteria and more. Updates are made interactively in response to user actions and according to the user’s process definitions. The video also shows how running processes can be monitored and reported on to improve process visibility.

Talmia can be used to support any ALM process from project start-up and iteration management through to development and testing. Talmia is available now for TFS 2008 with a 2010 version coming in March.

For more info see Terry Clancy’s recent blog post or go directly to the video demo or web site for Talmia.

Brian

A last comment on editor/IntelliSense improvements

bharry — Mon, 14 Dec 2009 14:43:21 GMT

I got some data on some of the changes the languages team has made from Scott Wiltamuth (PUM of the languages team).

The first change is in the message dispatching priority that we do in keystroke processing. As a user is typing code that involves statement completion UI, we have a choice to make about the relative priority of (a) processing the keystrokes and (b) displaying and rendering the statement completion window. The VS 2008 behavior was to delay the processing of IntelliSense presenters until the WM_KEYDOWN queue is empty. As we transitioned the editor to WPF, the relative priorities changed. Changing them back to something closer to the VS 2008 behavior made a huge difference. The new code is show below, with the change highlighted (in case you can’t see the highlight, it’s “DispatcherPriority.Background”):

public void QueueSpaceReservationStackRefresh()

{

    if (Interlocked.CompareExchange(ref _queuedSpaceReservationStackRefresh, 1, 0) == 0)

    {

        this.Dispatcher.BeginInvoke(DispatcherPriority.Background, new DispatcherOperationCallback(delegate

        {

            Interlocked.Exchange(ref _queuedSpaceReservationStackRefresh, 0);

            if (!_isClosed)

            {

                _spaceReservationStack.Refresh();

            }

            return null;

        }), null);

    }

}

This one change generated huge wins on some of the typing tests that we use – between 39% and 55% from one build to the next!

The second change was to re-use rather than re-create the statement completion window, so that when you type o.Foo.Bar, we reuse the statement completion window that displayed “Foo” for the statement completion of “Bar”.

Combined, these performance wins will make a big difference, especially for fast typists who have slow graphics hardware or are using virtualization. Here are the % changes for some of our C# typing scenarios:

PU	Scenario	B2Rel.21006 (Run 22042)	vs_langs.21201 (Run 23531)	% Change
VSL C#	Typing - Add classes at end of Large File	71,961.75	47,747.25	33.65%
VSL C#	Typing - After Top Level Edit	117,091.50	54,787.00	53.21%
VSL C#	Typing - In a Deeply Nested Object Initializer	90,684.00	30,404.75	66.47%
VSL C#	Typing - In a Large Method	118,181.50	55,767.25	52.81%
VSL C#	Typing - Large Collection Initializers	170,896.75	83,959.00	50.87%
VSL C#	Typing - Query Expressions	117,562.25	32,993.50	71.94%

Brian

Requests for access to VS 2010 post Beta 2 SLCTP builds

bharry — Mon, 14 Dec 2009 13:46:00 GMT

Since I posted my offer to hook you up with one of the Super-Limited Community Technology Preview builds, I have received a number of requests. I'm happy to do it but I want to clarify one thing. A few people seem to have the assumption that the build will be more stable than Beta 2 and therefore a great upgrade for their daily use. It's possible, but it's not likely. That's not why we are distributing them. We are distributing them so that people can test if specific issues that they reported in Beta 2 (particularly performance) have been addressed for them.

When we ship a Beta, we go through a multi-week stabilization period designed to gradually improve the quality by reducing the churn and fixing/avoiding regressions. The SLCTP builds have no such period. They are just daily builds that have passed the nightly verification tests. That means they should mostly work but there could be very bad regressions lurking that haven't been discovered yet. We get hundreds of checkins every day and any one of them could introduce a serious but not immediately obvious regression.

If you tried Beta 2 and you experienced (and hopefully reported) a specific issue and you want to verify that the issue is gone (and are prepared to re-report it if it is not), then an SLCTP build might be for you. If you are hoping for a new build that will just overall improve your development experience over Beta 2, the SLCTPs are not for you. We are working on a plan to provide another more broadly available better stabilized pre-release VS 2010 build. That will be your best shot at an overall better experience.

We greatly appreciate your help in tracking down the remaining issues so that we can ship a great product!

Brian

Why do we require NDAs on our SLCTPs?

bharry — Sun, 13 Dec 2009 12:26:36 GMT

Last night, I got the following question in email and it seemed like a good one and worth sharing the answer more broadly.

I'm just a bit curious about why you have an NDA for your SLCTP's. The purpose of NDA's is to prevent people talking about all the new great stuff in upcoming releases. I would imagine at this stage the products are feature complete; only performance and bugfixing left.
You yourself have gone publicly out and said that performance kind of sucks in the Beta releases. So it's not something anybody else will trumpet on their blogs and use as an example of how crap Microsoft products are. The only thing I can see is that people will say that performance is great; and I would have though that was a message you would want to put out as much as possible.

No, it has nothing to do with that.

Let me start by saying I am not a lawyer. I’m passing on the legal advice we’ve been given and I haven’t drilled into it to really understand the reasons behind it. When we are given legal advice that I think really compromises our business decisions, I do sometimes drill into it and will put pressure on the legal team to find better solutions. In this case, I didn’t feel this was an onerous issue, and we had bigger fish to fry – like actually working on the perf issues being reported, so I let it go.

Our goal is to turn out the SLCTPs quickly and with very little overhead. We generally start delivering them to customers within a few days of the build completing. In order to do this, we have to bypass a lot of our release verification – some security verification steps, legal compliance steps, etc. We still do some – like code signing and virus scanning but a bunch is skipped. The legal team has told us that to distribute builds that have not gone through the full release process like these, the must go to a limited number of people and they must be under NDA. By distributing SLCTP1 to >50 people, I think we’re pushing the limits of “a limited number of people” but not too bad.

In general, I don’t care if you talk about the perf or not. In fact, if you have constructive feedback, even if painful to read, I want to see it. But, unfortunately, you can’t talk about it relative to the SLCTP builds for the reason I gave. We’re working on a plan for a more broadly available, non-NDA build. I’ll let you know when we know more.

Thanks,

Brian

Blend Feedback on SLCTP1

bharry — Sat, 12 Dec 2009 17:37:10 GMT

About a week ago the Blend team upgraded to our SLCTP1 build (Super-Limited Community Technology Preview). We’re starting to get some anecdotal feedback from them and we’re planning to do another survey this coming week that will include everyone who tried SLCTP1 (a couple of internal teams and over 50 external customers). Before I share the new feedback with you, let me share some Beta 2 feedback. I have to say it is painful to read, even now – after I’ve read through it numerous times over the past couple of months. The thing I always have to keep reminding myself is “it was a Beta, it’s not supposed to be ship ready – it’s supposed to be a good vehicle for feedback”. Here’s one of the verbatims from the Blend team after they adopted Beta 2:

“If VS shipped today, I would not use, install, or buy the product, based on the performance. If I had any choice I would not use it at work either (Blend requires .NET 4). It is virtually unusable, and I am extremely unsatisfied with the performance. This product is a huge impediment to my productivity. VS2008 worked fine, using VS2010 is a struggle every day.”

Please join me in a collective “OUCH!” Let me also say that there are plenty of people who are very successful with Beta 2, but clearly the Blend team was not :(

Now to give you some contrast, here’s some quotes I got from the Blend team in email yesterday (based on their adoption of SLCTP1)…

1. Solution load time was incredibly slow

2. Once solution was loaded, trying to actually edit a .cs file was very slow with lots of hourglasses, not responding, etc.

I am incredibly happy to report that he just gave me a build with a fix for number 1. He found that hint paths were being resolved unnecessarily and repetitively when loading our solution. We tested his fix and the results are astonishingly fast! :)

Open Blend test solution on a fairly old machine with fixed build (FAST!)

versus

Open Blend test solution on slightly faster machine with our old VS build (VERY SLOW)

I must say I am very impressed with their responsiveness and the impact that these fixes will have for us, let alone all of our external customers!

And this one…

Wow!!!

I just tried it and it is amazing. Virtually no wait time.

Once the solution is loaded, I open a .cs doc and being editing immediately. I also tried editing in a document that was already opened upon load. It too was immediate.

Incredible!

We are feeling spoiled over here today.

Not done yet but the progress is really good. We’ll keep whacking away at it. SLCTP2 is going to be available this coming week. This one will still only be available under NDA but if you’ve had performance problems with Beta 2 and you’d like to get a change to see how it’s progressing, let me know and we’ll sign you up. We’re looking at a plan for a more broadly available (non-NDA) build – stay tuned for more info.

Brian

“Real World” Apps

bharry — Fri, 11 Dec 2009 16:04:19 GMT

Someone asked me the other day what we were using as our “Real World” apps so they could compare them to their own apps to understand how the testing we are doing will apply. Here’s a high level overview that characterizes several of them. There are others that I haven’t listed but this should give you a decent flavor. Many of these came from actual external customers and the names have been changed to protect the innocent :)

App	Type	Projects	Source files
AG	VB WinForms	120	942
SW	Mixed (incl C++)	167	2655
P	C# WinForms	29	1393
UM	C# Web Project	12	439
CB	VB Web Project	37	2297
TZ	C# Website	11	1021
PJD	C#, XAML, Silverlight	8	1200

I’m not trying to tell you that no one has any apps bigger than this but we believe these represent a pretty good picture of a range of largish real world apps across a variety of technologies.

Brian

Update on Solution Load Performance

bharry — Fri, 11 Dec 2009 15:18:00 GMT

One of the areas we’ve gotten a lot of performance feedback from Beta 2 on is loading solutions. We’ve made a ton of progress addressing the causes of the slowness. Like on the virtual memory issue I talked about yesterday, we’ve picked a set of “real world apps” – some of the same ones and some different ones to measure solution load time. Most of them are pretty big. I haven’t forgotten that I own you some data about how big these “real world” apps are. That’s next on my list. Again I’ve obfuscated the names to protect the identities of some of the customers who shared their apps with us but where the abbreviation matches with the VM charts you saw, they are the same app (for example: AG and CB).

The good news is that in most scenarios, we are now faster than VS 2008 (Orcas), in fact in some cases substantially so, for example: AV and TZ are almost twice as fast. Here is a chart comparing them (Main 21130.00 is the build from the Main branch on Nov 30th). You’ll notice we still have a few regressions with bugs filed on the more significant ones. As you can see a couple of measurements are still missing.

The first line (Open Dev10) is just measuring the raw time to start VS (for comparison to loading a solution). Ultimately, we are not going to get the raw startup time of VS 2010 to be as fast as VS 2008 but we continue to make progress on it and I don’t believe that is the most important metric. You'll see below a 1s startup regression in the fix queue and there's more improvements in the works, however, having startup be aa bit slower isn’t deadly if the rest of it runs pretty fast.

I suspect you are wondering what is “High-end hardware” and what is “Typical hardware”.

High End: Compaq DC7800, 2.4Ghz, dual core, 2G, 8M L2 cache, 667MHz memory speed, Tier 2 WPF graphics card, SATA 300 w/ 8M disk cache
Typical: HP Proliant DL145 1.8Ghz Pentium 4, single core, 1G, 1M L2 cache, software rendered (graphics card is considered Tier 0 by WPF), ATA 133 w/ 2M disk cache

Here’s our list of active investigations for solution load:

You’ll notice a couple of our internal customers I mentioned in an earlier post (Expression Blend and Exchange) in the list of active fixes and investigations. BTW: Don’t read that 12/19 (RC) to mean anything. I don’t know why it says that – our RC plans have nothing to do with 12/19. I suspect they are just saying that by getting in by 12/19 it will be sure to make it into the RC (which is definitely true).

I’ll continue to update you on other areas as we make progress and I get time to write about them.

Brian

Status update on post Beta 2 performance work

bharry — Thu, 10 Dec 2009 13:36:29 GMT

We continue to drive for improvements – trying to make contact with every person who reports issues (via my blog, Connect, Surveys, etc.). We’re released on “Super-Limited Community Technology Preview” to individuals who have reported problems and are on the brink of releasing another.

Every day we are seeing wins. One of the many issues we’ve been tracking the last few weeks has been that localized/international installs were substantially slower than English (yeah, I know you are thinking that would be hard :)) – on the order of 2 times slower in some cases. Just this morning I got word that a WPF improvement has been tested and we are now nearly at parity with English. There’s also a resource loading fix in the pipe that should erase any remaining issues. It looks like one more problem is down and we’ll keep cranking on the rest.

I thought I’d share a few quotes we received from customers who have tried out the LCTP1 build. I’ve asked for numerical data in addition to anecdotal but the anecdotal also makes a nice read.

Scrolling performance seems much better; it's now actually usable with a single core enabled and a lot better with 2 cores as well! Awesome! Scrolling using PgDown/PgUp also seems a lot better, particularly with 2 cores it seems pretty snappy.
I think you’ve absolutely identified the issue and I appreciate you working with me on this. VS2010 ROCKS!
They’ve improved things so much for me that it has become hard to reproduce the problem!
It's still a lot better than on beta2. It is much, much appreciated!!!!
Overall I'm seeing improvement on the performance front, but my ability to assess that is still noticeably impeded by stability and functional issues.
Stack overflow crash on converting a particular Makefile project.
Stepping speed in disassembly view is improved now that 511266 has been fixed, but it is still unsatisfactory.

We are also making a big push to get all of our internal dogfooders to update to SLCTP 2 and will be following up with a survey once people have had time to get a feel for it. We’ve picked up several key dogfooding teams that we’re working closely with on their experience, including: Expression, Exchange and CodePlex in addition to the Visual Studio teams.

We’re not done but it’s good to see some progress. SLCTP 2 should be better and by the time we get a more broadly available RC out after the first of the year, I’m very optimistic that the problem will be gone and Beta 2 will have proven very successful in helping us make sure we ship a great product.

Brian

Another Virtual Memory Tip

bharry — Wed, 09 Dec 2009 13:58:36 GMT

In truth, this won’t apply to very many of you and it is with some trepidation that I share it. The last thing in the world I want is for everyone to blindly follow it. This, like in many things in software, involves trade-offs that you need to think hard about.

VS 2010 includes more managed code than any previous version of VS. Also more of the managed code is NGENed (precompiled and saved on disk to avoid just in time compilation cost). As we’ve investigated the VM exhaustion issues (approaching the 2GB limit) we’ve seen some effects from this.

Before I go into the effects, let me set one more piece of context. In the early planning and development for this release, we were toying with significant changes to the VS deployment model to make the vast majority of it “xcopy deployable”. We ultimately decided not to try to deliver that for this release but it’s still in our aspirations. As part of our initial foray into this, we moved a whole bunch of our assemblies that had previously been placed in the Global Assembly Cache (GAC) out of it to better facilitate xcopy deployment.

When we started looking at our VM usage more closely in the Beta 2 timeframe, we noticed that a whole lot of files were mapped into memory twice (for instance: Microsoft.VisualStudio.TeamFoundation.Client.dll and Microsoft.VisualStudio.TeamFoundation.Client.ni.dll). The first one is the image with the IL in it and the second one is the image with native code in it that has been NGENed. Double loading so many DLLs uses up dozens of MBs of VM in an application of this size.

Upon further investigation, we learned that the CLR will often load both the IL image and the NGEN’d image when the IL image is stored outside the GAC. Moving the assembly inside the GAC eliminates the load of the IL image – loading only the NGEN’d image.

Now, hearkening back to my first paragraph, this actually sounds much worse than it is for most applications. The IL image (although mapped into memory) is not actually used for anything. The performance impact of this “double mapping” is nearly non-existent. Further it’s much better in .NET 4 than it was in .NET 3.5 because there actually used to be a performance hit in 3.5 (and earlier). In .NET 3.5 and before, if the assembly was strong name signed and NGENed, not only did it map both images, it actually verified the strong name on the IL which involves both CPU and I/O cost. In .NET 4.0 for the security model has been updated to only verify the strong names on images coming from untrusted locations.

This issue is something that people should think about if they have an app where the 2GB VM limit is a significant consideration but be aware that moving stuff into the GAC comes with its own issues. For one thing, it means your install can more “impactful” on the system than otherwise because your components are in a shared place where other applications can take dependencies on them. It also means you can’t just copy your app onto the computer – you have to install things in the GAC with GACUtil. There are installation permission implications and more. I don’t intend to turn this post into a “best practices for what to GAC and what not to” – I suspect there’s plenty of material out on the web for that – just be aware that it’s not a magic bullet that everyone should shoot.

When we first realized the impact this was having on the VS virtual memory situation, we spent several weeks with the .NET Framework team trying to determine if they could change this behavior and eliminate the “double loading”. After quite a bit of prototyping, we concluded that WAY too much code needed to be changed in the Framework and that this is a better fit for the next release. The loader is one of the most delicate parts of the CLR and even VERY subtle changes in semantics, ordering, timing, etc can result in 3rd party applications breaking.

Instead, we chose to pursue the path of analyzing our VS assemblies and determining which ones made sense to move back into the GAC. That work is largely complete and we’ve found that the savings are on the order or 50-70MB of VM across a sampling of scenarios. It’s not a huge amount (compared to 2GB) but it’s a very nice step in the right direction given them most of our scenarios were only over by a couple of hundred MB.

Brian

Looking at Virtual Memory Usage

bharry — Tue, 08 Dec 2009 14:51:27 GMT

One of the big problems that I’ve talked about is virtual memory exhaustion and the resulting VS instability. Today, VS is a 32-bit process – I’m sure that’s going to change (become 64-bit) at some point but it won’t for 2010. A 32-bit process has 2GB of address space on a 32-bit OS. You can throw the 3GB switch and get another GB at the cost of taking a GB away from the OS – it works OK but the OS doesn’t always like it – particularly if you are running server components on your machine (like IIS). If you are on a 64-bit OS, 32-bit processes get a full 4GB of virtual address space without any penalty to the OS – handy eh?

In the end, many customers are still running on 32-bit OSes and asking them to go change boot parameters (the 3GB switch) just isn’t an appropriate thing for us to do, so we’re focusing on making sure VM works well in the 2GB of address space that many customers have available.

This can be complicated by Virtual Address space fragmentation. This is caused by smallish gaps between other virtual address space allocation. You can reach the point where there’s enough virtual address space left but there’s not enough contiguous space to satisfy allocations. So saying everything is OK as long as virtual memory allocation stays below 2GB really isn’t realistic. The app will become unstable well before that.

Further, any test we do has to take into account that users will always do some things we didn’t expect so running VM all the way up to the threshold and saying “good enough” just isn’t acceptable either.

So what do you do?

We’ve started by gathering some “real world apps”. By this I mean some of you, our customers, have actually given us copies of your large apps. We’re incredibly grateful for this because they are great tools to ensure that we are staying in touch with the kinds of apps our customers are building and how VS is working for them. Oh, and we’re using a couple of internal MS apps as well. We’ve chosen 6 of them (apps of various types: web, WPF, Sharepoint, etc) that are all large and we believe characterize a large portion of our customer base.

We then choose a set of operations – load the solution, edit some code, design some forms, debug, checkin some changes, etc, etc that represent a realistic end user interaction with each application.

And lastly, we’ve chosen a threshold or 1.5GB of VM. We will not consider it acceptable until all 6 of the scenarios are able to execute without ever going over 1.5GB of VM. We believe this will allow adequate room for users to do things we didn’t anticipate and still have a buffer before getting near the instability threshold.

Here’s a picture of where we currently stand with the 6 apps (btw, I’ve changed the names of the apps to protect the identity of people we are working with). Most of these apps were RED when we started the VM effort a couple of months ago. As you can see we’ve made some good progress but we aren’t done yet.

Let’s take a look at some detail on one of the “bad ones”. Here you can see the way we are tracking this. You can see the “steps” in the scenario, the virtual memory after each step and the comparison to VS 2008 SP1 (for all steps where there is an equivalence). You’ll see there are more bars here than steps listed, I think that’s an artifact of the slideware (not all steps are listed). We use this to look for any places where VM jumps significantly or varies substantially from VS 2008 to focus investigations.

We also plot the VM growth from different builds against each other. In this case, you can see that in the Nov 11th build (21111) the CB died halfway through the scenario because it ran out of VM and you can see that by Nov 25th (21125) we had improved it so that that not only did it complete but it is generally better than VS 2008 (let us remember that VS 2008 isn’t flawless so we don’t blindly take parity with it as success). As you can see we still have a bit of work left to do to hit out 1.5GB goal.

We also track improvements over time from build to build in more of a trend fashion:

And lastly we use a “ledger” format for tracking fine grained progress. This is the best way I’ve found to track this kind of thing: Identify the goal and current status against it. Identify the fixed currently in progress and the expected improvements (generally an informed guess) and identify the areas that are under investigation (the things that just don’t look right) and best wild ass guess you can make about how much improvement “ought” to be available based on what it is vs what you think it should be. This gives you a way to see things moving through the pipeline, understand progress towards the goal and make priority trade-offs.

Hopefully that gives you some insight into how we are thinking about the VM issue and the progress we are making.

Brian

Visual Studio Testing Tools Roadshow in Chicago and Milwaulkee

bharry — Tue, 08 Dec 2009 12:44:00 GMT

Angela Dugan (Binkowski), a friend of mine in the field, asked that I help her advertise a roadshow she is doing. Here’s what she had to say about it:

Visual Studio Testing Tools Roadshow and Deep Dive

Ram Cherala, Principal Program Manager in the Visual Studio Test Tools Business, will be visiting the Midwest District to provide a deeper dive into the innovative new capabilities being introduced in Visual Studio 2010 Ultimate, Visual Studio Test Elements and Test and Lab Management products.

These sessions are targeted toward Developers, Architects, and Quality Assurance teams. Attendees will be given the unique opportunity to have a first glimpse into the products and interact directly with the Redmond team responsible for designing and delivering these products to the market. We will cover a broad range of important topics including Software Quality Assurance, historical debugging, manual test runner, test impact analysis and test lab management.

Agenda:

8:30am – 9:00am................. Introductions and Continental Breakfast

9:00am – 10:30am............... VS 2010 ALM Tools: Walkthrough of All New Features

10:30am – 11:30am............. 2010 MSDN and Licensing Updates

11:30pm – 12:00pm............. Lunch (provided by Microsoft)

12:00pm – 2:00pm............... Deep Dive and Demos of VS 2010 Quality Assurance Features (Coded UI Testing, Manual Test Runner, Lab Management, etc)

2:00pm – 2:15pm................. Break

2:15pm – 4:00pm................. Quality Assurance Tools: Migration and Integration Options

4:00pm – 4:30pm................. Feedback, Book Raffle & Zune Giveaway

This is a FREE event – Register now to reserve your seat!

Date	Location	Register
Milwaukee Monday, December 14, 2009	N19 W24133 Riverwood Drive, Suite 150 Waukesha, WI 53188	Register Here
Chicago (Downers Grove) Wednesday, December 16, 2009	Neudesic 377 E. Butterfield Road Suite 440 Lombard, IL 60148	Register Here
Chicago Thursday, December 17, 2009	Microsoft Office Aon Center Office 200 East Randolph Drive, Suite 200 Chicago, IL 60601	Register Here

	Ram Cherala is the Principal Program Manager in the Visual Studio Test Tools Business, which is part of the Developer Division at Microsoft. Ram is very passionate about building a well-integrated set of tools and technologies that enable developers build, test and ship quality software.

Book raffle and Zune Give-a-way

One random attendee will be selected to receive a brand new Zune HD!

Some WPF Designer Performance Improvements

bharry — Tue, 08 Dec 2009 00:35:00 GMT

We've heard loud and clear that the WPF designer performance in Beta 2 was unacceptable. Well, in a good kind of way, we knew that before we shipped Beta 2. This was one case where our performance tests were telling us the right thing. We discovered some issues late in the Beta 2 cycle (partially a regression, I think) and didn't have time to fully test a solution to address the performance issues. We did code it up and include it in the Beta but you have to use a registry key to enable it. Here's thread on it if you want to give it a try:

http://social.msdn.microsoft.com/Forums/en-US/vswpfdesigner/thread/4511d43f-c134-4329-a970-e374252a620e

This change will often address slowness and random pauses in the WPF designer. It's not the only cause but we've found most people who try it see good results. We've since had time to finish it and it is on permanently from here on out.

Today I saw some perfmon graphs that demonstrate how WPF designer overhead is improving over time.

This first graph is from Beta 2 without the reg key flipped. The very first spike is the CPU hit to open a C# file. the rest is the CPU hit to open an empty XAML file.

Here's the state with the reg key flipped. Don't be suprised that the reg key didn't make a huge difference in this scenario. It makes a much bigger difference in other scenarios.

And here's the current graph for the same thing with current bits. As you can see, it continued to improve.

Brian

WPF TreeView performance tip

bharry — Mon, 07 Dec 2009 19:42:00 GMT

Another of the many performance issues we hit (trust me not all of them were WPF related, it just so happens that the first two I've blogged about were)...

http://blogs.msdn.com/permanenttan/archive/2009/11/20/wpf-treeview-memory-consumption-and-performance.aspx

We hit this in the tree view you use to select which branches you want to visualize change for. A 108MB savings (on an admittedly artificially large data set), not bad :)

Brian