macOS Performance

Our AnandTech Storage Bench trace-based tests are Windows-only, and running them on a Mac in a Boot Camp configuration wouldn't give us much insight beyond running the same ATSB tests on our usual desktop testbed. However, our suite of synthetic benchmarks uses the cross-platform FIO tool, so these tests could be easily adapted to run under macOS.

Our usual configuration for these tests has the drive under test as a secondary drive, with nothing on the drive other than the data written by the test itself. This is the best way to measure a drive's raw performance capability without any interference and minimal overhead, but that's not usually a very realistic configuration. Without our ATSB tests to give a more real-world picture to counterbalance the idealized synthetic benchmark results, we chose to reconfigure the synthetic tests to use a somewhat more realistic configuration. Instead of running the OS off a separate drive, the drives under test were used as the only storage attached to the system. A clean install of MacOS 10.14 Mojave was used on each drive, and instead of having the tests access the drive as a raw block device, the tests were run against ordinary files residing on the same APFS filesystem as macOS and the testing software.

The amount of data read or written by each test is the same as for our usual Linux-based synthetic benchmark results. However, with the overhead of a copy-on-write filesystem and background traffic from the OS getting in the way, and with an entirely different host operating system, the numbers below are not at all comparable to our previous results on our standard desktop testbed.

These tests were run on two different MacBook Pro systems: a base model 13" Retina MacBook Pro from 2015 with a dual-core Broadwell processor, and a high-end 15" Retina MacBook Pro (Late 2013 model) with a quad-core Haswell processor. The only attempt to tune the machines for performance was changing two sysctls to allow more threads to be used to handle asynchronous IO—necessary for testing higher queue depths, but not needed for real-world low queue depth workloads.

Random Read Performance

Our first test of random read performance uses very short bursts of operations issued one at a time with no queuing. The drives are given enough idle time between bursts to yield an overall duty cycle of 20%, so thermal throttling is impossible. Each burst consists of a total of 32MB of 4kB random reads, from a 16GB test file. The total data read is 1GB.

Burst 4kB Random Read (Queue Depth 1)

Consistent with our usual Linux-based testing, the two drives with Silicon Motion SM2262EN controllers (OWC Aura Pro X2 and HP EX950) offer the best burst random read performance. The WD Black SN750 fares poorly, ending up slower than the more recent Apple OEM drive but outperforming the older PCIe 2.0 Apple OEM drive.

Our sustained random read test adds higher queue depths to the score: queue depths from 1 to 32 are tested, and the average performance across QD1, QD2 and QD4 is reported as the primary score. Each queue depth is tested for one minute or 32GB of data transferred, whichever is shorter. After each queue depth is tested, the drive is given up to one minute to cool off so that the higher queue depths are unlikely to be affected by accumulated heat build-up. The individual read operations are again 4kB, and are taken from a 64GB test file.

Sustained 4kB Random Read

On the longer random read test, the Aura Pro X2 remains one of the fastest SSDs, and the Samsung 970 PRO is essentially tied. The HP EX950's performance was inconsistent between the two laptops.

At sufficiently high queue depths, the HP EX950 and Samsung 970 PRO develop small performance leads over the Aura Pro X2. Additionally, the 13" MacBook Pro is severely bottlenecked by its weaker CPU that is unable to keep the SSDs busy under these conditions.

Random Write Performance

Our test of random write burst performance is structured similarly to the random read burst test, but each burst is only 4MB and the total test length is 128MB. The 4kB random write operations are distributed over a 16GB test file, and the operations are issued one at a time with no queuing.

Burst 4kB Random Write (Queue Depth 1)

The modern NVMe drives all provide similar performance on this burst random write test, while the older Apple OEM drives are at a clear disadvantage but aren't unusably slow. The 15" rMBP has significantly better performance than the 13" with the modern drives, but both machines offer roughly similar performance with the original Apple SSDs.

As with the sustained random read test, our sustained 4kB random write test runs for up to one minute or 32GB per queue depth, covering a 64GB test file and giving the drive up to 1 minute of idle time between queue depths to allow for write caches to be flushed and for the drive to cool down.

Sustained 4kB Random Write

The results for the longer random write test are pretty similar to the burst random write test above. The modern NVMe drives all perform about the same, and the higher CPU power of the 15" machine compared to the 13" makes a bigger difference for these fast drives than it did for the original Apple SSDs.

Random write doesn't improve with higher queue depths under these test conditions. Instead, it is either flat or declining as the OS has to juggle more threads to issue IO, and there may be some locking somewhere in the filesystem and storage stack that's preventing the kind of scalability we see on Linux.

Mixed Random Performance

Our test of mixed random reads and writes covers mixes varying from pure reads to pure writes at 10% increments. Each mix is tested for up to 1 minute or 32GB of data transferred. The test is conducted with a queue depth of 4, and is limited to a 64GB test file. In between each mix, the drive is given idle time of up to one minute so that the overall duty cycle is 50%.

Mixed 4kB Random Read/Write

The Aura Pro X2's performance on the mixed random I/O test is comparable to the other recent TLC drives but a bit slower than the Samsung 970 PRO. The modern NVMe drives are about twice as fast as the Apple originals on the 15" MacBook Pro, but on the more CPU-limited 13", they Aura Pro X2 is only about 50-60% faster.

The recent NVMe SSDs all generally show performance increasing as workload becomes more write-heavy, but the 13" MBP's CPU bottleneck cuts off that growth for most of the second half of the test. The Apple originals show relatively flat performance across most of the test, but the older 512GB drive has a bit of the uptick at the end that we typically expect.

Introduction macOS Sequential IO Performance
POST A COMMENT

30 Comments

View All Comments

  • zepi - Wednesday, June 05, 2019 - link

    Maybe you could list the Mac models that this works with in a nice table? It is not that long of a list. Reply
  • crimsonson - Wednesday, June 05, 2019 - link

    Or you can go to the manufacturer's/seller's website and get the info? Reply
  • hasseb64 - Wednesday, June 05, 2019 - link

    so why did you not post it here then? Reply
  • Ryan Smith - Thursday, June 06, 2019 - link

    Hey, that's a good idea. Thanks! I've gone ahead and added a list. Reply
  • zepi - Thursday, June 06, 2019 - link

    Thanks!

    I didn't even realise that this would actually be an upgrade path to my old rMBP13.

    I wonder if the horrible mixed workload performance translate into a meaningfully slow zipping / unzipping performance.
    Reply
  • leexgx - Monday, June 17, 2019 - link

    maybe should add that its best not to even use these OWC ssds for these macs, as they have not fixed the power state bugs due to the mac it self (more so 2013-2015) and the SSD missing something proprietary (system has a high chance when it comes out of hibernate and crash as the drive is missing on wake up) Reply
  • ltcommanderdata - Wednesday, June 05, 2019 - link

    https://forums.macrumors.com/threads/upgrading-201...

    Being a NVMe drive specifically designed to upgrade Macs, I don't suppose the OWC Aura Pro X2 solves the problem of NVMe drives failing to be detected upon wake from hibernation in 2013-2014 Macs? The current workarounds for that generation of Macs are to either disable hibernation reducing battery life or patching the BootRom which isn't user friendly.

    It would have been interesting to see where Apple's Polaris NVMe drives stack up in your comparison since testing by @gilles_polysoft at Macrumors suggests it's still one of the fastest, most power efficient options compared to third-party SSDs. It was only offered officially in 2017 iMacs though so finding a pull or an Apple service provider willing to sell a new one to upgrade older Macs is difficult and expensive.
    Reply
  • Skeptical123 - Wednesday, June 05, 2019 - link

    That's a good point Reply
  • zsero - Wednesday, June 05, 2019 - link

    Yes, there is a big difference between 2013-2014 and 2015 Macbook Pros regarding how they work with NVMe drivers. After reading a _lot_ about it, I finally decided that for my 2013 rMBP 15 the best option is to buy an original "SSUBX" drive from eBay, as none of the NVMe drivers would work reliably. Reply
  • MamiyaOtaru - Thursday, June 06, 2019 - link

    "I don't suppose the OWC Aura Pro X2 solves the problem of NVMe drives failing to be detected upon wake from hibernation in 2013-2014 Macs?"

    It does not. https://forums.macrumors.com/threads/owc-launches-... The OWC rep finally acknowledges it after mistakenly saying hibernation was fine for a couple pages. Disappointing lack of knowledge for the products he is shilling
    Reply

Log in

Don't have an account? Sign up now