Visual Studio 2010

Two weeks ago, Microsoft released Visual Studio 2010 and with it, .NET 4.0.

I’m very excited about .NET 4.0 because this is the first standalone release of .NET since 2.0 came out, meaning that it doesn’t bundle any of the older runtimes. As you may know, .NET 3.5 is actually just .NET 2.0 with some more assemblies – all the magic required for LINQ, extension methods and lambda expressions happens in the compiler.

The new Visual Studio UI also looks very nice and the darker background puts the actual work (the code) into focus. But there have been some changes like the apparent removal of the Debug/Release combo in the toolbar and the ability to add your own External Tools to the Tools menu in the Express Editions (don’t worry, both are still there, I explain how to enable them a bit down in this article).

So I decided to write a small heads-up on why I think Visual Studio 2010 and .NET 4.0 are cool and how to get back your favorite options if you’re already used to the Visual Studio 2008 Express Editions.

Debug and Release Switches

The first thing that confused me was that Visual C# 2010 Express (same goes for Visual C++ 2010 Express) is missing the Debug/Release combo from the tool bar. I often compile libraries of different kinds and doing a release build every now and then is important to me.

Here’s where they’re hidden: Microsoft added a new “Basic Settings” mode to Visual Studio which is selected by default. You can toggle between “Basic Settings” and “Expert Settings” in the Tools menu:

You also might want to enable the “Show advanced build configurations” switch found under Tools -> Options -> Projects and Solutions -> General, which controlled whether you got the Debug/Release combo in earlier Visual Studio Express releases, though I have to admit that I haven’t found out yet what exactly it does in any of the Visual Studio 2010 Express editions ;)

Changing to “Expert Settings” also adds the “External Tools” compartment back to the tools menu. I used this a lot, for example to run my unit tests, because Visual Studio Express doesn’t support Add-Ins (otherwise I would have installed the excellent TestDriven.NET Add-In right away!)

Redistributable Size

A rather pleasant surprise was that .NET 4.0 is a stand-alone release that no longer bundles the earlier .NET releases with the installer. Don’t get me wrong, you still have all the assemblies from .NET 3.5 and then some, but they have been re-released as pure .NET 4.0 versions in order to break all dependencies on earlier releases for .NET 4.0.

This is great for indie game developers because the size of the .NET Redistributable had become a real issue in previous releases:

Who’d want to download a 250 MiB installer to play Tetris(tm)?

Parallel Extensions for .NET

Creating well-behaving multi-threaded applications not only is one of the most difficult challenges in programming today, even finding things to parallelize is also hard because threads aren’t the lightweight objects one might wish they were:

Assuming I had a number of tasks I wanted to run asynchronously, if I created a new thread for each task, my Athlon64 X2 6000+ barely manages to perform about 7,000 of these tasks per second.

Using the original ThreadPool from .NET 2.0, this number instantly rises by a factor of 10 to 68,000. A thread pool keeps a number of threads waiting (which by the way doesn’t use up any CPU power) and wakes them up as soon as work becomes available.

68,000 tasks per second may sound impressive, but if I just executed the tasks synchronously, I would gain another factor 10 improvement to 630,000. In other words, if you use threading for tasks the are too small, it will slow down your code by a factor of up to 10.

.NET 4.0 includes what was earlier known as the Parallel Extensions for .NET, a number of additions for the .NET framework to allow for the parallelization of micro tasks, made possible by some tweaks to .NET 4.0’s ThreadPool

Thanks to this, the ThreadPool from .NET 4.0 manages 130,000 tasks per second in my small example. That’s still 5 times the overhead of a plain method call, but pretty impressive compared to what you get if you use explicit threads.

Here are the numbers again as a neat bar chart: