1. I get the point of using a RAM disk. But to me it’s just another point showing the baddness of system like windows.

    I’ve ran a few simple tests myself on OS X. Using a RAM disk makes no difference here. The reasoning behind this is simple. OS X recognizes which files are accessed a lot and memory maps those files. This works for writes and reads. Since OS X is a unix like system all I/O operations to disk are handled by the kernel and the kernel is free to decide when to actually write the memory buffers to disk.

    Windows also has these sorts of optimizations, but apparantly “being smarter then your OS” still works with windows.

    The memory mapping of files is just about the only reason why a proper shutdown is important, both with windows, OS X and any other modern desktop operating system.

    Also I have seen someone perform these procedures on unit tests as well. Can’t remember if it was Peter or not.

    On another note, using ram disks can have a very significant benefit!! When running tests which change disk state, performing those changes on a RAM disk allows a very simple and speedy reset procedure. Just unload the ram disk from memory and reinitilize it, all data restored to a pristine condition.

    Jeroen Leenarts

  2. Like any other optimization method, your mileage may vary. In a small test suite, the test bottleneck is typically not IO bound, and testing using ram disk usually needs some extra setup work, negating most of the performance benefits. I think you really only should start considering this when you are exceeding the ten minute build mark.

    Peter Hendriks

  3. Jeroen does have a point in that the OS should make sure that files that are frequently accessed should be cached in memory, in fact that is what every modern operating system (including Windows) does. The real bennefit a RAM drive will have is that it prevents all updates to Disk. Even when your OS uses delayed writes all changes will eventually get written to disk.

    The same problem arrises with Databases, which usually guarantee Durability (aciD). This means that any committed transaction should allways be persisted to Disk. Even when you use a rollback transaction mechanism to reset the state of the database after the test, there will be IO involved to write the logfile etc. In this case I think A RAM drive could speed things up. I wouldn’t call this beeing smarter than the OS, the OS (of DBMS) has no way of knowing that you are not interested in Durability.


  4. Frank’s remark is a good one.

    Forced reads are circumvented by using a RAM disk. Might be a good reason to use RAM disks after all. ๐Ÿ™‚

    Jeroen Leenarts

  5. The reason why a ram disk is always faster is explained very well by Frank, and I assume even on an uber OS like the Mac OS X, using a ram disk can make a difference. ๐Ÿ˜‰ I did try this out for myself of course, and I did see significant performance gains. The reason I do not call any numbers is that it will probably vary dramatically, depending how much IO bound your test cycle is. In very small tests, the difference is probably none or worse, because using the ram disk reliably involves some extra setup. Resetting the ram disk does not seem more efficient to me than just deleting the files: deleting files should be even faster.

    Peter Hendriks

Comments are closed.