RAMDrive Build Cache

Saving your SSD (a little)

After the recent article comparing HDD vs SSD vs RAM, I thought I’d expand a little on using a RAMDrive as a build cache with Visual Studio 2015. Of note, this technique is pointless with Xcode as it already caches everything in RAM, so all you’d be doing is doubling the RAM consumed for a build.

Please note that again – this is hardly scientific and just ‘FYI’. My main interest in using a RAMDrive arose out of a need to avoid needless writes to SSD for large numbers of transient files which do not really require permanent storage.

Using the AMD(ATI) RAMDisk, configured to 1Gb on my Dev PC (32Gb Corsair Xtreme RAM, 3.4Ghz i5 64b CPU), and enabling ‘Build Timing’ in Visual Studio 2015 (Tools/Options/Projects and Solutions/VC++ Project Settings), and then doing a clean build of Dominium on the Mac Air results in the following results;

SSD Build Cache

666 (Game Engine Library)

Total 38116 ms
Lib 318 ms
Compile 37478 ms

Dominium (Game)

Total 72190 ms
BscMake 24876 ms
Compile 44179 ms
Link 2456 ms

RAMDrive Build Cache

666 (Game Engine Library)

Total 38336 ms
Lib 298 ms
Compile 37632 ms

Dominium (Game)

Total 68330 ms
BscMake 23578 ms
Compile 41744 ms
Link 2795 ms


This is an interesting set of results. I’ve no idea why the engine library or final link took longer on RAMDrive (Just One of Those Things TM), but overall it shows no substantial improvement in build times (although I’ll take the 4s improvement 🙂 ). It does demonstrate that the file access times on SSD and RAMDrive for small files are more or less in line with each other which is pleasing to know. I didn’t _actually_ expect compile times to improve as they are all typically small, discrete file accesses, however I did expect the debug symbol mapping, and linking to be substantially faster (relatively speaking) as both these stages involve operating with single, ‘large’ files.

Regardless, a RAMDrive saves using up your SSD’s precious write cycles on the transient slush (temporary files which are deleted after use) generated whilst doing a build. Of note, Visual Studio 2015 generated 535Mb of slush during the build over 559 files, which evaporated away after linking to leave 93Mb behind. So imagine half a gigabyte being written every single time you do a clean build, probably to the same SSD sectors every single time if you don’t add/remove other files so much… ok, so there’s no need to do a clean build all _that_ often, but still… RAMDisk is free! 🙂

As another aside, on migrating to VS2015, I had to increase my Mac Air RAMDrive from 512Mb to 1Gb to allow it to build Dominium, due to that wopping 535Mb requirement… VS2010 happily built using the 512Mb RAMDrive and barely half filled that, so clearly VS2015 is far greedier in the temporary file stage. I may yet ping the VS guys a question to see why…

Comments are closed.