Most storage benchmarks resort to low-level system calls which should bypass caching. There are several ways to work around read caching. In the end, I’ve worked around this by using a different method of checking versions on the second occasion. When those apps try to check on the new version, macOS returns information which it has cached for the original file.

If you’ve ever written code for macOS, you’ll be aware of its tendency to cache information for surprisingly long periods: it’s a problem I’ve encountered when SilentKnight or LockRattler install a security update. Except that, if you’ve only just written that data to the file (or read it), it could cheat and, instead of bothering to read the data from the disk, it could just copy the data from memory.

Although you can ask the system to pause until the write is complete, there are no guarantees that it might not cheat.Īt first sight, caching read data shouldn’t have any effect: ask the system to give your app the contents of a file, and until your app has that data in memory, there’s little that a cache could do. When you write data to a disk, it’s normally fed to cache memory and written from there. This now incorporates two different read tests, and runs sequences of both read and write measurements, making it considerably more useful.Īs Ric Ford and others have pointed out, one of the big problems with trying to measure the performance of storage is caching. My measurements are made using a new release of my benchmarking utility Stibium. Although my focus of attention is comparing their internal SSDs, I’ll also compare them against a couple of external SSDs for reference. I’m referring to an iMac Pro, which has its internal disk controller within the T2 SoC, and a shiny new M1 Mac mini. Comparing the performance of modern high-speed SSDs isn’t easy, and if you think it should be straightforward, I challenge you with some results here, for a couple of Macs.

Mac mini m1 upgrade ssd