Elden and Bob, the coathors of ramBunctious, have used RAM disks for as long as we've used Macs. We've loved using some of the RAM disk programs available, and we leveraged their speedy accesses to speed up our compiles and other disk-intensive tasks.
So why did we write our own?
Initially, it was because one of our favorites (it's included in the chart below) could not have multiple RAM disks mounted simultaneously. So if we wanted to retrieve a source code file on another RAM disk, we'd have to unmount the current RAM disk, mount the other RAM disk, copy the file to the hard drive, and finally remount the original RAM disk and use the file.
This was a headache, and we decided to write our own RAM disk program -- initially solely to address this drawback. But we decided that if we were going to go to the work of implementing our own RAM disk program, we might as well set lofty goals for ourselves.
These goals included:
Since our initial implementation of ramBunctious 1.0, we've enhanced ramBunctious regularly, adding features from time to time to guarantee that ramBunctious stays at the forefront of Macintosh RAM disk programs.
The RAM disk programs in this comparison are:
|Multiple RAM disks mounted simultaneously|
|Memory reclaimable without a restart|
|Save contents to disk|
|Real-time write-through to disk|
|Timed save to disk|
|Read/write "LED" access indicator|
|1||Most "reclaimable" RAM disks use the Process Manager heap. But ShrinkWrap stores its RAM disks in the System Heap. This memory is reclaimable when you put away a ShrinkWrap RAM disk, but it's not always easy to reclaim for applications to use. If a ShrinkWrap RAM disk is in the System Heap, and any other program happens to create a pointer in the System Heap above the ShrinkWrap RAM disk, then the System Heap is incapable of shrinking down once the ShrinkWrap RAM disk is put away. The System Heap is "stuck" wasting the RAM until the other program releases its pointer. And if an extension or some part of the MacOS happens to be the one that allocated the pointer, then that RAM could be wasted until a restart.|
|2||Not all Macintoshes allow the RAM disk to save at shutdown.|
|3||ShrinkWrap allows you to choose between using a disk image as a RAM disk or running it directly from the hard drive. If you run it directly from the hard drive, then it is indeed a real-time write-through. But if it is used as a RAM disk, there is no real-time write-through to disk.|
|4||If virtual memory is turned on, does the RAM disk program use VM? Or does it "exempt" itself from VM at the risk of lowering overall system performance? A lengthier explanation is in the glossary.|
Several timings were taken using the System Info utility in Norton Utilities 3.5. The disk cache was set to 128K as suggested, and virtual memory was off, and AppleTalk was inactive.
All RAM disks were run in the simplest configurations possible. For example, ramBunctious minimized extaneous processing as described in the performance part of the FAQ.
Only the RAM disk programs that work with OS 9 were tested.
Tests were conducted on a 500 MHz G3 PowerBook using the base set of system extensions and running from the AC adapter.
Here is the overall performance bar chart:
Throughput was computed for a range of chunk sizes. See the following graphs of read throughput and write throughput as the chunk size changes, and read throughput and write throughput of totally randomly-sized chunks. (Chunk sizes are described in detail in the glossary.)
In addition to the graphs of throughput, the "relative performance" graphs let us see how well the RAM disks stack up against each other. To clarify the relative performance of each RAM disk at each chunk size, the 100% level was arbitrarily set to the fastest RAM disk tested at each chunk size.
Here are the throughput and relative performance graphs for read operations.
Here are the throughput and relative performance graphs for write operations.
What follows is the raw data copied from a Norton Utilities 3.5 System Info test run on each RAM disk. The tests were performed with a 128K disk cache and no virtual memory, as suggested by System Info.
Here's the spreadsheet data.