I've been running some numbers over our solution to try and make things more efficient. While I was at it, I figured I would put 2013 head to head with 2015.

The main test I ran was to take a solution open in Visual Studio and make sure it builds. I then ran Clean Solution. Using a stopwatch (so accuracy +- 1-second values) I recorded how long it took to build. I repeated this 5 times, over three machines, once each with 2013 and 2015. So first, the raw numbers (in seconds):

Laptop1 - 2013 Laptop1 - 2015 Laptop2 - 2013 Laptop2 - 2015 Desktop - 2013 Desktop - 2015
70 55 63 49 60 52
76 51 64 48 60 43
75 45 65 47 57 39
76 44 63 47 60 35
78 45 62 45 58 43

The average results from this looks like so:

Laptop1 Laptop2 Desktop
VS 2013 75 63 59
VS 2015 48 47 42
Difference 27 16 17
Improvement 36% 25% 28%

And for completeness, I thought I would graph the data as well:

Visual Studio Build times comparing 2013 to 2015 across devices.


Across the board, we have significate improvements. Visual Studio 2015 is just faster. And since nothing obvious breaks for my solution, at this stage I will be using it as the faster choice going forward.

This test only ran across one solution with 30 C# projects, across 3 very similar machines, only 5 times each. For a more conclusive answer, you would want to run this across a whole range of extra solutions and machines. But from this limited view, I'm really impressed by the perf increase of builds that 2015 provides me, for my particular code base, at this point in time.

Other Findings

During this exercise of measuring I can across one other nice conclusion as well. Restoring NuGet packages on a large solution with a complex dependency graph is much faster when using the command line, rather than letting visual studio load them on demand right before a build. I didn't get any hard numbers yet, but it feels significant. It took 2-4 minutes for VS to finish loading NuGet packages before it started building, versus the same dependencies loaded from the command line in 20 or 30 seconds.

nuget restore src\mySolution.sln

It is true that I am using a locally hosted NuGet 2 server, and that could be a factor, so your mileage may vary. But I usually find that command line tasks do come out faster compared to GUI ones, and this is one I will change my habits over.