This article shows a few benchmarks I have run on the performance improvement that Dev Drive offers, using a real-life project I am (well, was) working on some time ago. The simple examples in this article should give you some guidance on what kind of performance you should be able to expect after adopting Dev Drive.
YMMV and the usual caveats apply, but hey – it’s still data you can use to decide if it’s worth the (miniscule) set up cost.
Background
A while ago, I set up a Dev Drive on my laptop, when I was getting to know the recently-killed Dev Home (Preview) application, that back then (6 months ago – which in developer tooling world is basically a lifetime) was the up-and-coming developer tooling home for the future.
I had wanted to give Dev Drive a proper go already before, but this was a great opportunity since I was looking into other stuff in the app then.
The process was pretty quick, and I moved my code to the new drive as I started working on new projects. I didn’t really notice much of a difference, though – so eventually I decided I need to actually test if I’m getting the ~30% build performance increases advertised.
Test setup
I grabbed a project I was working on some time ago, cleaned up its node_modules folder, and copy-pasted it from my Dev Drive (D:) to my normal SSD drive (C:).
I decided to run a few build (or related) commands with Measure-Command to see what the performance was like.
Running npm -i -f
Performance on normal (NTFS) drive:

So npm i -f took 29.652 seconds to finish.
Performance on my Dev (ReFS) Drive:

There, npm i -f took 18.831 to finish.
An improvement of almost 40% is nothing to balk at. Nice – we’re definitely seeing an improvement on the build times on Dev Drive. In short, the build on ReFS only took 64% of the time it took on NTFS.
Removing node_modules
Removing a lot of files is normally painfully slow on Windows. But part of that is because of NTFS – what about ReFS?
Removing node_modules on my normal (NTFS) drive:

So rmdir “node_modules” took 24.507 seconds.
And Dev Drive:

So on ReFS, removing the same node_modules folder took 9.212 seconds.
Again, a pretty clear improvement on the Dev Drive! The build on Dev Drive took less than 40% of the time compared to my normal SSD drive, which is of course even more impressive than the improvement on the build time. So in other words, the clean-up on ReFS only took 38% of the time it took on NTFS.
Running build tooling
We also have our own build tooling, that restores both Nuget and npm packages and builds our solution. It has some necessary orchestration on top of just the msbuild and npm run tasks, so in reality, most of the time this is the build tooling we’ll needs to use to build and run/serve our code.
I figured it makes sense to get the actual, real-world scoop on this as well – how long does it take our tooling to run on C:? And how big of an improvement will we see on the Dev Drive (D:)?
So I ran it for both.
Running the whole build for the solution on my normal drive:

Alright. Slow, but bearable. Interesting to see how fast it’ll be on Dev Drive!
Running our build tooling for the solution on Dev Drive (ReFS):

1.32.92.
Well Gosh-Ferking Dagnabbit. I’ll be darned.
The build took over 40 seconds LONGER on Dev Drive. This means that the build on NTFS took 57% of the time it took on ReFS. Or in other words, it took 75% longer to build on ReFS, compared to NTFS.
I couldn’t believe the result, so I re-ran it a few times. The variability was actually significant – I’d see differences of a 20 seconds between runs on the same drive – but the result was still very clear. Running our whole toolchain on NTFS was faster than ReFS, sometimes significantly so!
I then tried running both (without Measure-Command to avoid it messing with anything) at the same time:

This was actually the best run for Dev Drive – the builds finished within a few seconds of one another (NTFS was faster), but they were close enough for npm to claim both took 2 minutes.
Results
Long story short: The performance of the Dev Drive is absolutely fabulous in all other scenarios, except for the one that matters the most: using our build toolchain.
Your Mileage May Vary – I assume this won’t be the case for a lot of toolchains out there, so you might get more out of Dev Drive than I am apparently getting.
That said, setting it up only takes a second, and unless you mess up and create a virtual drive, it’ll place your code and build artifacts nicely on a separate disk partition.
The operation times for this particular project when using a ReFS Dev Drive (opposed to regular NTFS drive) ranged anywhere from -62% to +75%.
- Dev Drive performance increase in real life scenarios? - February 4, 2025
- Join my session at CTTT25 this week: Level Up Your Teams Extensibility Game with Blazor | Session materials from Cloud Technology Townhall Tallinn 2025! - January 28, 2025
- How to identify which wifi band your Decos are using? - January 21, 2025