VS2008 SP1 and .NET FX Beta Performance Improvements

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):


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


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


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


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


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.


·         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


Comments (13)
  1. VS2008 Service Pack 1 has been released. Some helpful links: Readme http://download.microsoft.com/download

  2. gOODiDEA.NET says:

    .NET Visual Studio 2008 SP1 Beta VS2008 SP1 and .NET FX Beta Performance Improvements Introducing JScript

  3. gOODiDEA says:


  4. DevCorner says:

    The SP1 Beta for Visual Studio 2008 and .NET 3.5 has arrived. The beta of service pack holds a few improvements

  5. Zunanji viri says:

    There are various enhancements and even changes in SP1 . Perhaps one of the most interesting is the change

  6. Does the ASLR enhancement improve NGEN performance for assemblies with overlapping or identical base addresses?

  7. David Berg says:


    I haven’t personally tested it, but yes, ASLR should improve performance for NGEN’d assemblies with overlapping or identical base addresses – but only on Vista and Windows Server 2008, since those are the only two Operating Systems that support ASLR.  Here’s why:

    Without ASLR executable binaries (including NGEN’d assemblies) are loaded at their preferred base address.  If that’s avalailable, only the pages that are actually being used are loaded.  If the preferred address is not available, then the DLL is loaded at another address and fixups are applied, which forces all pages with fixups into memory, and makes those pages non-sharable and dirty, so they have to be written to the page file if they’re paged out.

    With ASLR on, the binary’s preferred base address is ignored and the binary is loaded in a high memory region the OS reserves for such binaries.  However, no fixups are applied at the time, so no excess pages are read, nothing is marked dirty, and all pages are shareable.  Then as the binary is used, pages are read and relocated on the fly by the Kernel.  Because this is done by the Kernel, it’s transparent, and the cost is very small (compared to the cost of reading the page into memory in the first place).

    So performance is theoretically better because:

    1) We don’t take a hit for relocating the binaries.

    2) We don’t have to write modified binaries to the page file.

    3) The binaries remain shared, so memory pressure is reduced when multiple copies of the application are running.

    Note that if for some reason there is a memory conflict AFTER ASLR is applied, then the binary may still be relocated through the standard User Mode mechanisms employed for non ASLR binaries.

    Also note that IL assemblies contain no fixups, so they can be located anywhere in memory (so ASLR doesn’t really apply).  However, the JIT’ed code is then loaded in non-shared paged memory.  So if paging or memory sharing is important, NGEN is probably the better way to go.

    Hope this helps,

    David Berg

  8. David Berg says:

    The details on the WPF performance improvements in this release have just been posted.  


  9. Le Service Pack 1 de Visual Studio 2008 est actuellement en beta et en anglais. Il sera disponible prochainement

  10. David Berg says:

    The Web Developement team just posted an update on Switching to Design View.  You can read about it here: http://blogs.msdn.com/webdevtools/archive/2008/06/18/faster-switch-to-design-view-in-vs-2008-sp1-rtm.aspx.

  11. We just announced the release of Service Pack 1 for VS 2008 and .NET FX 3.5 . A major push for this release

  12. Hozer says:

    A question about ASLR. For .NET 3.5 SP1 I was wondering if ASLR is only available for ngen’d assemblies? Or is there a compiler flag setting for this? Or is ASLR automatic? i.e. one does not need to do anything except run the assembly on vista or win2008?


  13. David Berg says:

    IL assemblies contain exactly one relocation address (used to bootstrap the runtime), Windows Vista and 2008 understand this and all IL assemblies (ver 2.0 SP1 or later) are automatically opted in for ASLR.

    Additionally any 3.5SP1 NGEN generated images will have the ASLR opt in bit set.

    You can do a

                   Link /dump /headers EXENAME

    and look for the ‘Dynamic base’ characteristic to determine if an EXE has opted into ASLR:

                440 DLL characteristics

                      Dynamic base

    (Thanks to Vance Morrison and Landy Wang for helping me get this right, any mistakes are mine, not thiers.)

Comments are closed.

Skip to main content