RAM File System benchmarks: methodology and how to reproduce

This page documents exactly how we measured the numbers on the RAM File System product page and in the RAM Disk comparison. Everything here was run on a single computer in one session, using standard tools, so you can repeat it yourself.

The test machine

ComponentDetail
ProcessorIntel Core i9-13900KS
Memory96 GB DDR5
Operating systemWindows 11 24H2
RAM FS volume64 GB
RAM disk volume64 GB NTFS
SSDSamsung 990 PRO NTFS

Ground rules

  • Same machine, same session. All three targets were tested back to back on the identical hardware, so the only variable is the storage.
  • Windows Defender real-time protection was off. It otherwise intercepts file operations and adds noise that is not part of the storage itself.
  • Best of a few runs for the timed tasks, to remove one-off outliers.

Synthetic throughput and IOPS (DiskSpd)

We used DiskSpd, the same engine CrystalDiskMark runs on, with the flags CrystalDiskMark uses. The key flag is -S, which disables the operating system cache so the numbers reflect the storage itself. Swapping -S for -Sb repeats the test through the cache (the buffered path that ordinary programs use).

A 1 GiB test file is created first, then each pattern is measured. Examples:

:: sequential 1 MiB reads, queue depth 8, 4 threads
diskspd -b1024K -o8 -t4 -W0 -S -w0 -si -ag -d5 -L R:\test.dat

:: random 4 KiB reads, one at a time, single thread
diskspd -b4K -o1 -t1 -W0 -S -w0 -r -ag -d5 -L R:\test.dat

:: random 4 KiB writes, queue depth 32, 4 threads
diskspd -b4K -o32 -t4 -W0 -S -w100 -r -Z4K -ag -d5 -L R:\test.dat

The tables below give throughput for each target, then how far ahead RAM FS is against the RAM disk and against the SSD. A positive figure means RAM FS is faster.

Unbuffered, single thread, GB/s

ScenarioSSDRAM diskRAM FSvs RAM diskvs SSD
SEQ 1M, QD8, read7.147.450.4+6%+611%
SEQ 1M, QD8, write5.461.768.6+11%+1162%
SEQ 1M, QD1, read2.713.420.1+50%+634%
SEQ 1M, QD1, write4.323.243.4+87%+906%
RND 4K, QD32, read0.71.93.8+98%+460%
RND 4K, QD32, write1.01.83.3+83%+239%
RND 4K, QD1, read0.12.04.7+129%+9012%
RND 4K, QD1, write0.11.93.9+110%+3143%

Unbuffered, four threads, GB/s

ScenarioSSDRAM diskRAM FSvs RAM diskvs SSD
SEQ 1M, QD8, read7.145.073.4+63%+929%
SEQ 1M, QD8, write6.568.868.2-1%+950%
SEQ 1M, QD1, read7.144.137.4-15%+425%
SEQ 1M, QD1, write4.648.262.8+30%+1270%
RND 4K, QD32, read1.84.59.6+111%+421%
RND 4K, QD32, write2.64.08.1+103%+212%
RND 4K, QD1, read0.25.011.1+123%+4796%
RND 4K, QD1, write0.74.39.1+113%+1155%

A couple of rows go the RAM disk’s way at four threads: bulk sequential writes are a tie, and one low-queue sequential read is a little behind. We show every number rather than a hand-picked few. Everywhere else RAM FS leads, and against the SSD it leads by a wide margin, most of all on small random reads taken one at a time, where the SSD is held to about 12,500 operations per second by its latency while RAM FS answers over a million.

Buffered, single thread, GB/s

ScenarioSSDRAM diskRAM FSvs RAM diskvs SSD
SEQ 1M, QD8, read8.07.849.4+533%+516%
SEQ 1M, QD8, write6.76.768.1+918%+923%
SEQ 1M, QD1, read8.58.219.5+138%+131%
SEQ 1M, QD1, write6.56.542.7+558%+558%
RND 4K, QD32, read1.41.42.8+98%+98%
RND 4K, QD32, write1.31.33.4+172%+174%
RND 4K, QD1, read1.71.63.1+92%+83%
RND 4K, QD1, write1.51.64.1+160%+166%

Buffered, four threads, GB/s

ScenarioSSDRAM diskRAM FSvs RAM diskvs SSD
SEQ 1M, QD8, read13.714.171.4+407%+420%
SEQ 1M, QD8, write12.012.270.0+472%+484%
SEQ 1M, QD1, read16.216.737.0+122%+128%
SEQ 1M, QD1, write12.112.560.8+387%+404%
RND 4K, QD32, read2.32.37.0+211%+207%
RND 4K, QD32, write2.12.19.2+340%+339%
RND 4K, QD1, read2.52.47.9+229%+221%
RND 4K, QD1, write2.22.210.3+373%+370%

Buffered is the way ordinary applications read and write. Here the SSD and the RAM disk land in almost the same place, because both are served by the Windows file cache rather than by the device, which is why the vs RAM disk and vs SSD figures are nearly identical. RAM FS does not use that cache and serves files straight from memory, so it stays several times ahead of both.

Real-world tasks

These use everyday tools, timed with a stopwatch. The archive is a 7z of the full Apple open source collection (apple-oss-distributions), a source tree of 649,000 files, about 10 GB unpacked. Times in seconds, lower is better.

Extract, delete and copy a large tree

:: extract 649,000 files
7z x macos-src.7z -oR:\tree -y

:: copy the tree (32 parallel threads)
robocopy R:\tree R:\copy /E /MT:32

:: delete the tree
rd /s /q R:\tree
TaskSSDRAM diskRAM FS
Extract 649,000 files144.8 s101.0 s59.8 s
Copy the tree, 32 threads69.9 s37.1 s7.4 s
Delete the tree39.2 s17.2 s6.7 s

What ties, and why

Work limited by the processor rather than by storage finishes in about the same time on all three targets. Compiling code is the obvious example: the bottleneck is the CPU, not the disk. That is worth stating plainly: RAM FS helps wherever storage is on the critical path. When the processor is the limit instead, there is little left for faster storage to give.

That said, a build is still worth pointing at RAM FS even when the clock barely moves. Compilers and linkers produce a great many short-lived intermediate files, and keeping those in memory spares your SSD the constant writing and deleting. That prolongs the drive's life and keeps the clutter of temporary files off your permanent storage.

Further reading