A couple of years ago, in 2023, Microsoft released a new feature called Dev Drive, which is supposed to speed up common developer tasks. In the announcement blog post Dev Drive for Performance Improvements in Visual Studio and Dev Boxes! they show some impressive numbers with an average of 25% speed up. It is built on the new modern ReFS file system and requires Windows 11, but otherwise no special requirements.

This sounds great, right? But how much faster is it really?

I got a new laptop recently and thought this was a great opportunity to try it out and get some extra performance out of it "for free".

Setup

The Dev Drive itself can be installed in two modes, either on a disk partition or as a VHD. Using a disk partition is supposed to be faster (but less flexible), and this is what I used. The machine I tested on is a reasonably powerful Lenovo Thinkpad with 16 cores and 64GB RAM, and a big SSD disk.

I wanted to try a couple of different typical tasks I do as a developer, and compare against both a standard folder on the C drive, and a folder excluded from antivirus. This was a good opportunity to test WSL as well, is Linux better or worse for development? I picked 3(4) open source libraries for this experiment:

• Caddy is a well known and well regarded web server made in Go.
• Pymunk is my own physics' library, built in Python.
• Polly is the default resiliency library for C#/.NET, made in C#.
• Mapperly is one of the best mapping libraries in C#/.NET, made in C#

Note: I started with Mapperly and then switched to Polly. Mapperly didn't compile equally easy on Linux as on Windows, and I didn't want to spend time troubleshooting. And regardless, Polly is an even more widely used library.

I used two types of actions to benchmark, clone, and build. (Pymunk is built with the default c-compiler for the platform, which is VS on Windows and GCC on Linux. In this test we are not interested in comparing compilers, therefore I skipped building it)

To easily measure the time I wrapped it in all in a PowerShell script, using the Measure-Command command to measure the time. Each test ran 20 times.

    (Measure-Command { git clone "https://github.com/caddyserver/caddy.git"}).TotalSeconds
    (Measure-Command { git clone "https://github.com/viblo/pymunk.git"}).TotalSeconds
    (Measure-Command { git clone "https://github.com/riok/mapperly.git"}).TotalSeconds
    (Measure-Command { git clone "https://github.com/App-vNext/Polly.git"}).TotalSeconds
    cd caddy
    # replace paths for each environment
    go env -w "GOPATH=d:\devdrive-bench\gopath" 
    go env -w "GOCACHE=d:\devdrive-bench\gocache"
    go env -w "GOMODCACHE=d:\devdrive-bench\gopath\pkg\mod"
    (Measure-Command { go build -a }).TotalSeconds
    cd ../Polly
    # replace path for each environment
    $env:NUGET_PACKAGES = "d:\devdrive-bench\.nuget\packages"
    dotnet clean
    (Measure-Command { dotnet restore }).TotalSeconds
    (Measure-Command { dotnet build src/Polly.Core/Polly.Core.csproj  --no-incremental --framework=net8.0 }).TotalSeconds
  

Result & Analysis

To look closer at the data, let's do some visualizations. A good start is to look at the decision tree at data-to-viz.com to decide what kind of visualization to use. In this case, it looks like the box plot is a good choice. To plot my go to Python library is Seaborn. It has a nice high level interface and produce good looking plots directly out of the box.

There were a couple of outliers in the data. I do not think they are directly related to the drive choice, but instead random external causes, like fluctuations in the Wi-Fi connection or slack notifications. I did not boot into a completely clean state before running the tests. (I did however change the power mode to minimize any CPU throttling). To not skew the results by these, I used the Interquartile Range (IQR) method to remove outliers outside of Q3 + 2 x IQR.

Plotting with box-plot with Searborn yielded these plots (lower is better):

Summarized as a table with how much each option are faster (or slower) in average from the baseline of NTFS, it looks like this (which those with a speedup of at least 20% bolded):

At least for .NET development, it does look quite good for the Dev Drive, more or less consistent with the numbers Microsoft presented. (Looking at Git clone it's a different matter!). But, as the well known quote Lies, damned lies, and statistics hints at, this is not the full picture. Let's take a look at the median instead:

Oh, now the numbers for the Dev Drive are nowhere near a 20+% speedup. Actually this reflects my own impression better while preparing this post, and I think it better matches the diagrams above. WSL still showed a great improvement when building Caddy, but in the other tests the improvements got cut in half.

I hope that this shows how easy it is to show a specific outcome. Even when you want to do a good analysis its difficult and easy to trick yourself.

The raw data is available here log-20250913.csv, a Jupyter Notebook rendered as HTML here devdrive-notebook.html and the raw notebook here: devdrive.ipynb.

Conclusion

The results are not clear-cut. If you can/are allowed to exclude folders from Windows Defender then that is an easier option compared to the Dev Drive with more or less the same result. What I do think is clear is that if its possible then using Linux is a great option! For unrelated reasons I recently switched from Windows 11 to Linux Mint on my private laptop, and based on this test it was obviously a good thing to do.