Developer Division Performance Engineering blog : Visual Studio

Looking at Virtual Memory Usage

David Berg — Tue, 08 Dec 2009 15:43:00 GMT

Brian Harry is continuing a great series of posts on VS2010 performance, you can read the latest in that series here; where Brian talks about the issues we've been seeing around Virtual Memory Exhaustion and what we're doing to address it.

Improving the Start-up Performance of the WPF and Silverlight Designer in Visual Studio 2010 Beta 2

David Berg — Mon, 02 Nov 2009 18:34:00 GMT

I wanted to let you know about a last minute change that went into VS 2010 Beta 2 that you can use to improve the startup performance for the WPF and Silverlight Designer. The change went in late and it was a little risky, so we decided to leave it off until we had a chance to do some more testing with it. You can turn the change on yourself via a registry key. We expect the change will be on all the time in the final product, so changing the registry key is strictly a Beta 2 issue.

If you have any feedback on how this works (or doesn't work) for you, please let me know. You can contact me at DevPerf@Microsoft.com.

Regards,

Dave

VS2010 Performance and Bad Video Drivers/Hardware

David Berg — Fri, 30 Oct 2009 05:49:00 GMT

We’ve received a few performance complaints around Visual Studio 2010 (Beta 2) performance that can be traced to old video drivers or GPU virtualization issues.

If you’re seeing slow / broken screen updates verify you have the latest drivers for your system. If this doesn’t resolve your rendering issues, you may be able to work around the problem by forcing software emulation mode by changing one registry key:

[HKEY_CURRENT_USER\Software\Microsoft\Avalon.Graphics]

"DisableHWAcceleration"=dword:00000001

As you can probably guess, this can be undone with:

[HKEY_CURRENT_USER\Software\Microsoft\Avalon.Graphics]

"DisableHWAcceleration"=dword:00000000

If you have these issues, please, let me know by either posting here or preferably by e-mailing DevPerf@Microsoft.com with details about the problems you are/were seeing. (When you e-mail, please run DXDIAG first and attach the DXDIAG.TXT file. This will give us a lot of information about your system, including what drivers you’re running.)

We’re very interested in finding any hardware/software incompatibilities we might have missed and getting them cleaned up.

If you do find you need to use software emulation, and then get new drivers or hardware later, don’t forget to switch software emulation back off so you can benefit from the improved performance.

Note that this will impact all WPF applications on the system, not just Visual Studio.

Regards,

Dave Berg

Developer Division Performance Team

Tell us about VS2010 Beta2

David Berg — Thu, 29 Oct 2009 21:49:00 GMT

Last week we shipped Beta 2 for broad distribution. Many of you have already sent us comments and improvement suggestions (thanks!)

At this point we are down to our final set of bug fixing, perf tuning, etc. We’re very interested in your feedback so we can take action on it before we ship the final version. To help make it easy, you can take this simple survey.

One thing in particular we are hearing a lot of feedback on is performance. We are working hard on the next round of perf improvements. You can supply your feedback through the survey. When you give us your feedback, the more actionable you can make it the better. We need to know what operations you are doing (like editing, debugging, etc), what kind of hardware you have (CPU, RAM, disk), and your hosting scenario (main machine, running in VM, terminal server, etc).

Thanks in advance for your feedback!

Dave

P.S. If you'd like to talk to me directly about your performance experience, you can reply here or e-mail us at DevPerf@Microsoft.com.

Visual Studio 2010 Hardware Requirements

David Berg — Wed, 24 Dec 2008 10:56:00 GMT

Soma’s been talking about the upcoming Visual Studio 2010 release on his blog, which means I’m starting to get questions about what type of hardware you’re going to need to run VS2010 on.

Unfortunately, I can’t give you an official answer yet (other than to say, it depends on what you’re doing – obviously building small apps with one of the Express versions of Visual Studio won’t require the same resources as a multi-million line app using full blown Visual Studio Team System with lots of third party add-ins).

What I can do is help put some of the things we’ve said about Visual Studio 2010 into context, to maybe help you make some better hardware decisions today:

1) Memory – we’re trying to make VS2010 as frugal as we can here in order to run in as little memory as possible; however, we’re also adding a lot of functionality, and systems with more memory do tend to perform much better. So the general rule of buying systems still applies – spring for as much memory as you can afford. It’s hard to have too much memory, at a minimum you want to make sure that you’re not paging. That said, there’s very little benefit to making a text editor 64 bit (and lots of reasons not to), so anything over 4GB is likely to be wasted (unless you’re running or writing apps that need more).

2) CPU – modern CPUs with their larger caches and tuned instruction pipelines tend to perform much better than one’s from just a few years ago (see our blog). If you’re going to do multi-threaded programming, you’ll want at least a dual core processor (and with the new Parallel Computing support in VS 2010, you will want to do multi-threaded programming).

3) GPU – VS2010 will leverage WPF heavily to create richer editing and visualizations, so a decent GPU that supports at least DX9 is highly recommended (DX10 is preferred, but requires Vista).

4) Disk – If you’re building a large project or working with a large database, a large high-speed disk is pretty important. For large projects, you can often benefit by spreading your work across multiple disk spindles. At an extreme, putting your tools on one drive, your source code on another, and your object files on a third drive allows the three major sources of disk IO in building a project to be carried out independently of each other. If you have to use a slower disk (e.g. a notebook) then be sure to get lots of memory. Also keep in mind that modern hard drives tend to have more built in caching, so the same speed drive bought recently will likely outperform one bought a few years ago.

So now that I’ve given you my thoughts on what hardware Visual Studio 2010 will need, what are your thoughts? What kind of hardware are you developing on today, and what do you expect to be using in the next couple years? What are your expectations on how we should be leveraging your hardware to create a productive development environment?

Lessons from the test lab: investigating a pleasant surprise

jonathanh — Thu, 19 Jun 2008 00:33:20 GMT

This post describes our recent investigation into an interesting performance problem: benchmarks that we were surprised to find running significantly faster than we expected on new hardware. Along the way we discuss useful benchmarking tools, how to validate results, and why it pays to know exactly what hardware you're running on.

This all started in our performance test lab. During the development of Visual Studio, each new build undergoes a suite of automated performance tests, running in a lab full of identical machines. These performance tests allow us to track Visual Studio's performance over time, and detect performance regressions (when something gets unexpectedly worse). We recently added a batch of new machines in our lab, and that's when the fun started.

Pop Quiz: How Much Faster?

Old machine: dual-core Intel Pentium D 830 processor, running at 3 GHz, with 1 GB of RAM.

New machine: quad-core Intel Xeon 5355 processor, running at 2.66 GHz, with 4 GB of RAM.

Given the differences in the two hardware configurations above, how much faster would you expect the new machine to be when running a Visual Studio performance test? Lower than, same as, twice, three times or four times the performance of the older machine?

One line of reasoning might look at the relative clock frequencies of the processors on the two machines. This might lead you to expect the newer processor cores to perform slower than the older cores, since their clock frequency is 11% lower. By this reasoning you might conclude that single-threaded applications would perform poorly on the new machine.

Another line of reasoning would factor in the number of cores in the two systems. Since the new machine has twice the number of cores, you might expect it to have about twice the performance on multi-threaded applications. (If you also accounted for the lower clock frequency, you'd end up with a figure of 1.78 times the performance of the old machine.)

A third approach might estimate the impact of RAM size. We’ve quadrupled the amount of RAM, so maybe any benchmarks that used to page to disk can now execute entirely in memory and hence will be orders of magnitude faster. [We'll cheat here and tell you that our benchmarks are generally not memory constrained].

So far, all these options seem plausible. What's your guess?

What we naively expected to find lay somewhere between the first two lines of reasoning - that the new machines would be 1-2 times faster than the old machines, depending on the particular benchmark.

What we actually found is that many of our single-threaded CPU-bound benchmarks run about twice as fast on the new machine, while scalable multi-threaded benchmarks run up to four times as fast. This was a pleasant surprise, because it significantly reduces the overall time to run all the benchmarks. But it did leave us wondering why we were getting much greater speedups than our naive explanations would suggest. The rest of this post explores that question.

Using WinSAT and SPEC to Validate Benchmark Results

To make sure this wasn't a fluke result, we used the Windows System Assessment Tool (winsat.exe). This is a built-in tool that can give quickly give a representative view of a machine's performance. It is multi-threaded, taking full advantage of all the cores on a machine. Here are the WinSAT CPU results:

Benchmark	Old Machine	New Machine	Speedup
CPU – Compression (MB/s)	70.5	262.0	3.7
CPU – Encryption (MB/s)	52.3	139.3	2.7

We also wanted to validate our results against other real-world benchmarks. For this we turned to the SPEC website. SPEC produces a series of benchmark suites, plus a very formal process that ensures results are reproducible and can fairly be applied across different manufacturers. More importantly for our purposes, SPEC posts all reported benchmark results on their web site. You won’t always be able to find your exact machine listed, but after using results from a tool like CPU-Z you can generally find results from a machine with the same CPU configuration and clock speed.

We used the "CINT2006" benchmarks – this is a widely-used benchmark suite concentrating on integer performance. We compared results for both CINT2006, which is a good test of single-threaded performance, and CINT2006 Rate, which tests the ability of a system to execute multiple copies of CINT2006, and is therefore a better test of multi-threaded performance. For two representative machines that are similar to our old and new hardware, here are the results:

Benchmark	Old Machine	New Machine	Speedup
CINT2006	9.85	15.5	1.6
CINT2006 Rate	18.0	44.4	2.5

The WinSAT and SPEC results confirm that the new machines are much faster than our naive expectations, even for benchmarks such as CINT2006 that cannot take advantage of the extra cores. So what were we missing?

Using CPU-Z to Examining Machine Configurations

To answer this, we need a deeper understanding of the configurations of the two systems.

Unfortunately, finding detailed configuration information isn't always straightforward. For example, we know that level two (L2) cache size impacts performance, but Windows doesn't report it, and it's not easy to reboot into the BIOS to take a look at cache size when the machine is located in a remote test lab. This is where machine reporting tools like CPU-Z come in. You can run CPU-Z remotely on an unknown machine and get back a nicely formatted HTML report showing exactly what the hardware is. Here's a deeper look at our old and new systems:

Feature	Old Machine	New Machine
CPU name	Pentium D 830 (“Smithfield”)	Xeon X5355 (“Clovertown”)
CPU speed	3.00 GHz	2.66 GHz
Number of cores	2	4
L1 cache (per core)	16 KB	32 KB
L2 cache (total)	2 MB	8 MB
System RAM	1 GB DDR2	4 GB DDR2

Using BCDEdit to Disable Cores

Now we can try to tease out the relative impacts of the many changes from the old configurations the new configurations. The first and easiest step is to disable two out of four cores on a new machine, to enable a fairer "apples to apples" comparison of cores between old and new machines.

To do this we used the Windows BCDEdit tool, which replaces the old method of editing BOOT.INI by hand. Here we were particularly concerned with the order in which cores are disabled. This is important because the 8 MB of L2 cache in the Xeon “Clovertown” processors is divided: two of the four cores share 4 MB, and the other two cores share the other 4 MB. To keep our benchmark comparisons as fair as possible, we wanted to make sure that only one of the L2 caches was in use after disabling two cores. We used CPU-Z again after rebooting to confirm this.

Now we were in a position to do a fairer “cores to cores” comparison between the old and new machines. Here's a summary from WinSAT:

Benchmark	Old Machine	New (2 cores)	Speedup
CPU – Compression (MB/s)	70.5	131.9	1.9
CPU – Encryption (MB/s)	52.3	69.7	1.3
Memory Bandwidth (MB/s)	4,041	3,360	0.8

Now we can really see the advantage of the latest processors – on a core-for-core basis, they are 1.3-1.9x faster on the CPU-intensive WinSAT benchmarks, despite having lower clock frequencies.

Good, now on to the next… wait a second. Look at that memory bandwidth result. Our new machines have less memory bandwidth than the old machines? That doesn't look right: although memory performance hasn't been keeping pace with CPU speeds, it has been improving over time. Compared to a three-year-old machine, we'd expect these new machines to have slightly better memory bandwidth, and definitely not worse. What gives?

Memory Channels

A primary limiting factor to memory bandwidth is the number of memory channels that are in use. And this turns out to be the problem here: although the new machines have four memory channels and eight memory slots, only two of those slots are filled, because the vendor supplied us with two 2 GB memory modules per machine. This maximizes future expansion potential – we can take the machine up to 16 GB without throwing away any of our initial investment in memory. But in the meantime using two memory slots limits us to two memory channels in use. If instead we had four 1 GB memory modules we'd have four memory channels in use, improving memory interleaving from 2:1 to 4:1 and increasing memory bandwidth. To confirm this, we populated four memory slots on one of the new machines (going from 4 GB to 8 GB) and reran WinSAT:

Benchmark	2 channels	4 channels	Speedup
Memory Bandwidth (MB/s)	3,360	4,134	1.2

Conclusions

It's always possible to run more experiments to further isolate and explain benchmark results, but after a while you reach a point of diminishing returns. With the results we have so far, we can already draw some useful conclusions.

The first conclusion is that our naive explanations greatly underestimated just how much better the newer processors are at executing real benchmarks, despite their slower clock speeds. The results from WinSAT and SPEC clearly show this, with core-to-core performance that is 1.3-1.9x faster on the new machines, depending on the benchmark.

This is perhaps the most important lesson for developers to learn: clock speeds are no longer a good indicator of true performance. Although clock speeds have plateaued, processor designers continue to find ways to make each new generation significantly faster than the last. In our case, the old machines have Pentium D processors (“Smithfield”), while the new machines have Xeon 5-series processors (“Clovertown”). And while the newer processors have slightly slower clock speeds, their micro-architecture executes more instructions per clock cycle.

The second conclusion is that it's very hard to perform fair comparisons. The two machines have several configuration differences, including clock frequency, number of cores, core micro-architecture, cache sizes, bus speed, memory size and speed, and so on. We showed an example of isolating the effect of just one of these differences, the number of cores, using the BCDEdit tool. Isolating the effect of every single difference would require much more effort.

Indeed, some of these differences are interrelated, and it is hard to change one without affecting another. For example, CPU architects make their micro-architecture design decisions based on cache sizes. Now imagine a hypothetical experiment that tried to isolate the effect of L2 cache size by giving each core just 1 MB of cache. This would be especially hard on the newer processors, which have been designed on the assumption that they have 2 MB of L2 cache per core[1]. In trying to perform a fairer comparison, we would have actually handicapped one system!

Our final conclusion is that it truly pays to benchmark and compare systems. In our case, the simplest possible benchmark (WinSAT) showed an unexpected memory bandwidth loss, which we then traced back to a machine mis-configuration. So that was the final pleasant surprise: if we hadn't gotten curious about why the new machines were so much faster, we would never have found that they could be faster still!

David Berg
Sunny Egbo
Jonathan Hardwick
Peter Okonski

[1] Because two cores share a single 4 MB L2 cache on the Clovertown processors, the exact size of the cache that is used by each core is not fixed at 2 MB per core; the use will vary during program execution. Cache hungry threads might get more of the cache, while less cache hungry threads get less. Even when two cache hungry threads run on the two cores, their memory hotspots are asynchronous; thus, the net effect is that each thread gets more of the cache when they need it and less when they don’t need it.

Visual Studio Performance Testing -- Noise is Enemy #1

MarkBFriedman — Tue, 20 May 2008 03:25:00 GMT

Performance testing is essential to our quest to make Visual Studio provide a highly responsive user experience.

We do performance testing early and often. Before a new feature is checked into the main branch, a test build is created, and 100 to 200 tests are run to assess performance. These tests include scenarios for start-up, debugging, project build, editor interactions, and much more.

This sounds like a lot of work. Well, it is. But there’s even more work that takes place before a single bit is tested.

Here’s a brief summary of what we do. First, we work with Visual Studio product units (e.g., C#, debugger, XML editor, and about 30 others) to identify performance-sensitive user scenarios and to set response time goals for these scenarios. The product teams develop test cases for their scenarios. Our team, Developer Division Performance Engineering, reviews these tests to see if they meet certain acceptance criteria. Once a test has been accepted, it is incorporated into the division-wide suite that is used to assess if performance has degraded on a check-in. We call this a performance regression.

Of course, we need a test infrastructure as well. We have a hundred machines dedicated to performance testing. We also have automation software that runs tests, analyzes the results, and notifies product teams of performance regressions. Initially, our perspective was that automating performance testing has unique requirements that demand a unique infrastructure. Now, we recognize that performance testing has much in common with functional testing. Further, we want to use features such as load testing and test case management that are part of Visual Studio Team Test, a direction that is being pursued by Developer Division as a whole (in part to “dog food” Visual Studio features).

During a performance test, we collect a large number of PerfMon counters, CPU profiles, ETW traces, and more. However, the decision whether there is a regression (and hence if the changes can be checked-in) currently depends on just two metrics – CPU Time and Elapsed Time. If either of these is “significantly” higher than they are supposed to be, the check-in is rejected. (We deal with memory and I/O in other ways.)

But what constitutes significantly higher CPU Time and Elapsed Time? This question has been a source of animated discussions with developers eager to check-in their changes.

In the past, we used an adaptive but somewhat opaque approach to establish regression thresholds. The adaptive part allowed us to automatically reset performance baselines for regression thresholds, but it was done in a complex way. As a result, there were many times when developers contested that there was a performance regression because there was confusion about the performance baseline. One of the lessons we learned is that effective performance testing requires a transparent methodology for setting regression thresholds.

Our latest approach is to periodically set regression thresholds based on the results of multiple runs of the same baseline build. This provides a clear basis for comparing performance results on check-in.

This approach has another advantage as well – it allows us to eliminate certain sources of noise. For example, variations in the chip sets used on our test machines caused some machines to have very long I/O times (in excess of 20% longer). As a result, we developed a machine acceptance procedure whereby we eliminate these anomalous machines. There are concerns about tests as well. For example, some tests use very little CPU and so a seemingly significant increase in CPU Time can be due to very small changes in the way context switching takes place during the run. Indeed, even for CPU bound work, we have noticed CPU Time can vary by 5% to 10% due to changes in the way context switching occurs.

These are all examples of test noise. Properly addressing test noise is critical to the effectiveness of the performance engineering process. Nothing is more frustrating to a developer than to spend several days pursuing a performance bug that turns out to be noise.

Test noise is any characteristic of a test that makes it so that CPU Time and/or Elapsed Time vary so much that we can’t reliably determine if performance has improved or degraded. To assess whether a test is too noisy, we run it multiple times on the same machine with a baseline build, and see if we get similar results. By similar, we mean that results do not vary more than 10% from the mean of the run.

Below are results from a test with little noise for CPU Time. The horizontal axis shows the run, and the vertical axis is CPU Time in milliseconds. The asterisks are test executions or iterations that are done repeatedly within a run. In most cases, we do not include the first iteration because it often differs a great deal from the others due to initialization effects. (Of course, for start-up scenarios, we only use the first iteration!)

We look for several things to see if a test is too noisy. As in the figure above, we want all of the performance counters to lie within the range of plus or minus 10% of the mean. Also, we look for a fairly even scatter of performance counters below and above the mean, but with no discernable pattern. If there is a pattern, it suggests that something is systematically biasing the test and needs to be fixed.

Now, let’s look at some noisy tests. One case is that the test may actually be addressing more than one scenario with very different performance characteristics. Here’s an example of a test that appears to have this multiple scenario character:

Another possibility is that the test may occasionally do something that takes a lot longer, or the test may be so short that it is subject to intermittent activities occurring in the OS (e.g., lazy writes) or the CLR (e.g., garbage collection). Here’s an example of a test result that appears to have this kind of problem:

In this case, there are two extreme values. At first glance, it may seem that there is another problem as well since several of the iterations have values below the “mean-10%” line. However, this is an artifact of having two large values that make the mean larger.

It’s hard work to do all of this. But performance testing was central to performance gains in Visual Studio 2008 compared with previous releases. And, with the help of changes in our handling of test noise, more performance improvements are on the way.

We will share the best practices for performance testing that we develop for Visual Studio (and other Developer Division products) with our customers. Longer term, we hope to incorporate these best practices into Visual Studio tools so that you can be more effective with your performance testing.

by Joe Hellerstein, Ph.D.

Senior Architect, Developer Division Performance Engineering

Joe Hellerstein is the author of Feedback Control of Computer Systems, published by Wiley-IEEE Press in 2004. He had a long and distinguished career at IBM Research prior to joining Microsoft in 2006.

VS2008 SP1 and .NET FX Beta Performance Improvements

David Berg — Mon, 12 May 2008 19:38:00 GMT

You probably already saw Soma’s Blog on the Beta for Visual Studio 2008 and .NET FX 3.5 SP1. If you can, please download and install the Beta quickly (be sure to read the readme for Visual Studio Professional and for Visual Studio Team System first). The sooner we get your feedback, the sooner we can act on it.

Visual Studio 2008 SP1 is packed with new features, major updates to frameworks, and fixes. So much so that with everything installed (including x64 and ia86 support) you would need to download and install about 1GB of updates. Which brings us to the first and most important performance improvement – you only download what you need!

VS2008 SP1 includes a new installation / update engine. You just download the installer, which then analyzes your system installation, and only downloads the components you need. Thus a default installation of VS2008 Team System will only download about 600mb (and less still if you don’t have all the default components installed). Download performance will vary substantially based on your internet connection and network contention; however, it generally outperforms an IE file download, and will automatically restart in the middle if your network connection drops out and comes back. (However, if you cancel the install, it will restart at the beginning.)

The new installation engine is also much faster than VS2005 SP1, installing twice as much updates in less than half the time (typical install time is about an hour, if you’re running Vista RTM, you’ll want to upgrade to Vista SP1 before installing VS 2008 SP1, it’s much faster).

(The Express versions of VS SP1 are re-releases, not patches; however, they still use the intelligent patching/download logic for .NET FX and other components).

Here are some of the other performance improvements in Visual Studio 2008 SP1 and .NET FX 3.5 SP1 (includes .NET FX 2.0 SP2 and .NET FX 3.0 SP2):

Editing:

· Improvements in the WPF designer including a (10-20%) improvement in startup time.

· Improvements working with ASPX forms, Java Script, and web site building. Some parts previously released as KB946581.

Build:

· Improve Visual Basic build performance for projects that contain a large number of XML comments in a single file (such as a designer-generated dataset or web reference). Previously released as KB946344.

CLR:

· Improved working set and startup times for NGEN’d images (varies substantially by app).

· Support for Address Space Layout Randomization (ASLR) on Vista and WS 2008. Uses fast kernel mode virtual base address relocation to improve memory layout and security.

Debugger:

· Improvements in symbol and source downloading and the ability to cancel symbol download from slow symbol servers.

· Fix to a performance problem in the debugger when you are stepping through source code that is downloaded from Microsoft Reference Source Server that was caused by downloading the source files again for each breakpoint. Previously released as KB944899. (Note this fix is included in SP1. To improve the SP1 install experience, please uninstall this KB before installing the SP.)

Team Foundation Server (TFS):

Brian Harry has already blogged about some of the great things in this release. Here’s what he said about performance and scalability improvements:

· # of projects per server - Constraints on the number of projects per server have been written about quite a bit. In TFS 2008 SP1, we have made some important improvements. To refresh your memory, the primary issue is that the size of the cache that the TFS client downloads is proportional to the number of projects on the server. This cache can get very large (10s of MBs) and slow things down to the point that usability is affected. The changes we have made for SP1 include:

o Only download metadata for projects a user has access to. By only granting access to the projects a user needs, it will dramatically reduce the size of the metadata they download.

o Implemented cache compaction to remove some stale data from the cache that is no longer used. We have seen 30% or better improvements from this in some circumstances.

o Improved the speed of the Connect To TFS experience when there are a large number of projects in the list. We saw about an 80X improvement on one of our internal servers.

· Improved syncing identities from Active Directory - Our tests show syncing a group with 200,000 users dropped from 69 minutes to about 10 minutes. This can significantly reduce background overhead on a system with lots of users.

· Improved checkin concurrency - Checkins are globally serialized - meaning 2 checkins (overlapping or not) must be processed in order and the second must wait on the first to complete. In SP1, we were able to both improve the overall speed of checkin and reduce the blocking. The blocking period is now only about 1/3rd of the checkin time.

· tf branch /checkin - Creating new branches when they are large (ours are about 1,000,000 files) can be very time consuming. We have created an option for creating a branch that is much faster. tf branch /checkin creates the branch without first pending the changes and requiring a subsequent checkin operation. The result is about a 10X improvement in branch creation speed.

· Online index rebuilding - If you use SQL Enterprise with TFS, TFS will now rebuild indexes online allowing for less "downtime" for maintenance. If you use SQL Standard (which comes with TFS), then you will still get offline index rebuilding and your TFS server will not be responsive during weekly maintenance jobs. If your TFS database is small, it doesn't really matter but as it gets into the terra-bytes, online index rebuilds become a must.

· Team build support for very large checkins - In TFS 2008 and previous versions, a very large checkin (hundreds of thousands of files) would trigger an out of memory error in TFS Build and prevent CI builds from triggering. The out of memory issue has been fixed in SP1 and all checkins should properly trigger builds.

· Faster security manager - We found an O(N^2) algorithm in the security manager for version control and have replaced it with an O(N) algorithm. It will help version control performance across the board. We found it on large Get operations (getting hundreds of thousands of files). The change reduced the security manager time from 5-6 minutes to a few seconds. The end result is that those gets were about twice as fast.

· tf get /remap - Kind of a complicated feature but dang handy if you need it. This is a new option on tf get that is intended to be used when you want to switch your workspace from one branch to another in the same code base. You first change the workspace mapping and then issue a tf get /remap. Because a large percentage of the files in two related branches are frequently identical, this command optimizes for that. Rather than downloading all the content, it will only download the things that are different between the two branches. I can reduce the get of a very large workspace from 10's of minutes to a few seconds.

· Much, much more... - This is just a taste of the performance improvements we've made. As always, each release includes a roll up of performance improvements we've made for our own internal dogfooding of TFS. This release is no different. There are dozens of additional fixes that we've made to improve performance. If your installation is very large, you should notice nice responsiveness improvements across the board.

Additionally, this release does include KB947551 that some of you asked about (Improved right click to context menu performance on a project or solution in "Solution Explorer" with a large number of projects in TFS).

WPF:

We’ve made some substantial improvements in WPF performance. Some of these you get for free by just installing SP1, others require you to take advantage of new components or options. See the WPF Performance Blog for all the details.

SQL CE:

· Up to an 80% improvement in server to client sync services in ADO.NET.

Visual Studio Data Professional:

· Up to 5x faster (re)loading database projects (than VS2008 RTM).

· Up to 2x faster importing an existing schema (than VS2008 RTM).

Known Performance Issues in Visual Studio 2008 SP1 that are still outstanding:

· We haven’t yet fully resolved some Web Editing issues where you may experience poor performance when typing in design view or during design/source view switch.

· In the new Data Entity support UndoDeleteProductEntity is slower than we’d like, we expect to fix it for RTM.

For more information on .NET FX see ScottGu’s Blog. For more on Web Development tools in this release, see their team blog.

Of course, as mentioned before if you have any performance problems, we’d like to hear about them. For issues related to the Beta, please use the community forum: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=2136&SiteID=1

For issues unrelated to the Beta, you have the usual choices:

1) You can log bugs on Connect. Bugs logged there go directly into our bug tracking system and Connect provides a mechanism for communication, tracking, status, and other customers to comment.

2) You can e-mail the Performance Team directly at DevPerf@Microsoft.com.

3) You can post comments on this blog (you may need to sign-in first).

Best Regards,

David Berg

Senior Program Manager

Developer Division Performance Engineering Team

Microsoft Corporation