Quicker builds on Windows by using a RAM-drive

By | July 13, 2010

There’s been a number of blog posts lately celebrating the use of SSD-disks for reducing build/compile times and to make your IDE snappier.
This post is about an even quicker and sometimes cheaper alternative – mount a portion of your RAM as a drive and execute builds there! I also show you how to accelerate Maven and IntelliJ using this strategy.

I have 16GB RAM on my Windows machine (my customer demands that I use Windows) of which I normally use about 3GB. What I’ve done is to set 8GB aside for a RAM-drive. Files put on my e: drive are stored directly in system memory, no need to do the round-trip to a harddrive, waiting for the data to be copied into memory. I’m developing software in Java and use the RAM-drive for my Maven builds and installs. Also, I keep IntelliJ temporary files, indexes, etc. in memory.

On Linux/Unix and MS-DOS/older Windows versions RAM-drives are easily created using tmpfs or ramdisk.sys, but on new versions of Windows, Vista and later, built-in support for RAM-drives is lacking. Enter Dataram RAMdisk. This free software does the job nicely. Typically, you’ll need a 64-bit Windows version to access more than 4GB of RAM at the same time.

Create the RAM-drive

  1. Install RAMDisk
  2. Configure and create the RAM-drive.
    Configuration, part 2
    Select persistence settings of the RAM-drive. Remember to save your settings.
    Configuration, part 1
    Select the size of the RAM-drive and start it up.
  3. Using Server Manager, format the new drive as NTFS. After a wait of a couple of seconds, the new drive will show under “My Computer”.
    format the new drive
  4. [Optional] Disable indexing of files on the new drive. It is not worth it to have Windows build and maintain a search index for your build tree. Go to the new drive in explorer, for example e: and choose properties. On the bottom of the first page, uncheck “..index files..”
  5. Check out your code tree to the new drive
  6. Execute mvn clean package. Observe the difference in speed from building on your ordinary harddrive. In my case I get more than a 20% speedup, saving myself over five minutes on certain builds.

Put your Maven artifacts on the RAM-drive

Putting your Maven artifacts on the RAM-drive will speed up builds and installs.

The simplest solution is to just put your entire local maven repository on the RAM-drive by setting the local repository path in Maven’s settings.xml. For example, you change the location of the repository from c:Userssomeuser.m2reposistory to e:repository.

A more flexible solution, and the one I use, is to only put -my- artifacts on the RAM-drive.
I do this to save space, as my repository is a bit on the heavy side.
To get there, I used the built-inmklink command.
mklink allows you to create a directory that links to another directory.
That way I make the directory (c:someuser.m2reposistorymyartifact-root) point to e:repository-ramdisk.

The syntax is
MKLINK /J Link Target


C:Userssomeusertest>mklink /J mydir e:mydir
Junction created for mydir <<===>> e:mydir

 Volume in drive C is System
 Volume Serial Number is 1401-307B

 Directory of C:Userssomeusertest

06.07.2010  11:17              .
06.07.2010  11:17              ..
06.07.2010  11:17         mydir [e:mydir]
               0 File(s)              0 bytes
               3 Dir(s)  55 119 831 040 bytes free

C:Userssomeusertest>mkdir e:mydir

C:Userssomeusertest>cd mydir

 Volume in drive C is System
 Volume Serial Number is 1401-307B

 Directory of C:Userssomeusertestmydir

06.07.2010  11:15              .
06.07.2010  11:15              ..
               0 File(s)              0 bytes
               2 Dir(s)   2 102 341 632 bytes free

Make IntelliJ use the RAM-drive

Putting IntelliJ’s temporary files and indexes on the RAM-drive will make it snappier, especially for large, multi-module projects.

First, make sure you have the default setting of “use maven output directories” enabled, that will make IntelliJ create class-files on the RAM-drive.

Secondly, import or load the project from the RAM-drive, for example import e:srcmymodulepom.xml as a new project.

Finally, exit IntelliJ and copy IntelliJ’s system (c:Userssomeuser.IntelliJIdea90) folder to the RAM-drive (or selected parts of that folder if you’re short on free space).
Then rename the system folder and create a link with the same name, pointing to the folder on the RAM-drive (using mklink as in the previous section).

Make files on the RAM-drive persistent across reboots

There is of course the option of just checking out the source code and downloading the maven artifacts anew after a reboot. You can even script this task to do it automatically at startup.

If you want some file safety in case the computer crashes, there is a loss of power or so, you can have Dataram RAMdisk write the RAM-drive to disk automatically and regularly.
Also, it can persist and load the RAM-drive at shutdown and startup, by selecting the ‘auto save’ option as shown in the first screenshots. making the RAM-drive appear completely like a normal drive. Tweak the settings to your liking, and remember to save them 🙂

2 thoughts on “Quicker builds on Windows by using a RAM-drive

  1. laurent

    4 years later… it’s still an excellent advise 🙂 from 14mn to 2.5mn!
    Thanks 🙂

  2. Alexander Kriegisch

    Thanks for this article. Today (2021), the free version (personal use only) of Dataram RAMDisk only supports up to 1 GB max. disk size. An alternative might be the last freeware version of SoftPerfect RAM Disk which, according to the description (not tried yet) is only limited by the system memory and can create any number of RAM disks.

    Anyway, I tried Dataram RAMDisk first and used it with an open source software where the cloned repository + files after a ‘mvn package’ build already consumes 880 MB. during build it used more than the max. RAM disk space, so I checked directory sizes. 660 MB alone or 75% is used for the Git repo clone (yes, they have some binaries in their repo, sorry). So I tried to find out how to put the Git repo outside of the work dir. It was actually quite simple and can be done during cloning or even in an existing clone with already existing work dir:

    git init –separate-git-dir=../MyProject.git

    Now it was easy to reduce the RAM disk to 512 MB, about 2x the size of the work directory after a full build. That was enough for my benchmarks. I also saw a 20% performance win, similar to you (the author of this article). Putting the local Git repo onto the SSD also has a security advantage. Even if the computer crashes and the RAM disk is not saved, all your commits are still there. So if you commit quite often like me, you are safe like this, even if you don’t push to a remote all the time.

    I noticed that Maven builds outside of IntelliJ are a somewhat faster than inside (also Maven), probably because IntelliJ keeps indexing files (also in the target folders) for its wonderful search feature.

    Looking for further optimisation I check my IntelliJ directory. It is 2.5 GB in size because it has indexed many projects and about 5-10 JDKs, then some plugins like Kotlin and Scala (which I rarely use but are on the disk drive anyway) already eat about 260 MB. So putting that stuff on a RAM disk would start becoming difficult on a 16 GB RAM laptop.

    My local Maven repo is about 33 GB in size, but if I just want to speed up one project, maybe I could change the global settings while working on it and make it point to the RAM disk. One full build or something like ‘mvn dependency:go-offline’ in an empty .mvn directory (just rename the existing one) would show me exactly the dependencies my project of choice uses. Then I could switch back to the original, big .m2 directory and create soft links or junctions from the biggest subdirectories there to the RAM disk. At least for the project’s own artifacts that would help speed up both ‘mvn install’ and potentially also submodule builds after a preceding ‘mvn install’ on top level, because in this case the build has no full reactor and pulls previously built artifacts from the local Maven repository.


Leave a Reply

Your email address will not be published. Required fields are marked *