Why are Disk Images so slow at writing?

In yesterday’s article about lightweight virtualisation on Apple silicon Macs, I was critical of their Block Device storage performance, and attributed much of it to the use of Disk Images. This article follows that up by evaluating the read and write performance of different types of Disk Image, including those with encryption.

Encrypted Disk Images are important in macOS, as they’re currently the only supported way to protect individual folders rather than whole volumes. Way back in January 2017, before Apple released the first version of APFS, it promised that its new file system would support the encryption of smaller storage items. I wrote at the time that APFS “therefore allows you to choose from several options for each volume within an APFS container. These range from no encryption at all, to multi-key encryption with different files/folders protected by different keys, even a separate key for metadata.”

Sparse bundles are also used extensively, for instance when sharing volumes to store Time Machine backups over a network. If those suffer poor write performance, that will slow every backup being written to them.


To measure read and write performance of these different forms of Disk Image, I ran standard tests using my free app Stibium. In each case, the app first wrote a random sequence of files from 2 MB to 2 GB in size to the Disk Image, then read them in that same order. Whenever feasible, I used Disk Images of 100 GB in size and five complete sets of test files, making 80 in total, although in some cases limited free space prevented that. Disk Images were each created using Disk Utility, and saved to the internal SSD of that Mac.

Most results were obtained from a Mac Studio M1 Max with 32 GB of memory and a largely empty 2 TB internal SSD, running Monterey 12.4, although I have also checked some of these on two other Macs, an iMac Pro with its rather slower 1 TB internal SSD, and a MacBook Pro M1 Pro also with a 2 TB internal SSD.


The main results, from the Mac Studio, are summarised in this table.


While reading from each of the Disk Images was almost as fast as from the SSD, write speeds were severely reduced. The sparse bundle was least impaired, with a write speed just under half that of the SSD, but all three disk images wrote at less than 20% of SSD speed, with the encrypted disk image the worst of all, at less than 1%. To put that last write speed into context, that’s as slow as the innermost blocks on a rotating hard disk, and only twice the speed of burning to Blu-ray disc at 6x.

To confirm that the encrypted disk image performance wasn’t an anomaly, I repeated the same test on the two other Macs. Their write speeds were 71 MB/s (iMac Pro) and 52 MB/s (MBP M1 Pro).

On all types of Disk Image, write speeds were also more variable. For example, on the main test system with an encrypted disk image with its overall speed of 57 MB/s, they ranged from 20 MB/s to 3.1 GB/s. There was no obvious relationship between speed and file size, though.

It’s well known that macOS deliberately throttles some I/O, for example slowing Time Machine backups, to prevent background services from blocking I/O for user tasks. Although it appeared unlikely that this would apply to writing to Disk Images, I next examined in Activity Monitor what was happening when writing to an encrypted disk image.


To my surprise, the cores of an M1 Pro chip remain almost inactive during this period, between the figures 1 and 2 in the CPU History window above. There’s a small increase in CPU % on the two E cores, and a little on two of the P cores. The most active process listed over that period was diskimages-helper, which took a steady 23% CPU throughout the period. During an unencrypted write, it took just 26%.

Given the high write performance of the SSDs used, this can only indicate that macOS is intentionally throttling threads responsible for performing writes to the encrypted disk image, and to unencrypted disk images too.


This CPU History window shows CPU % for a series of unencrypted writes and reads. The peak at figure 1 represents the write series, and that at 2 the same files being read from that disk image. While writing appears to be throttled here, reading reaches a much higher CPU %, thus doesn’t appear to be limited to the same degree.

This difference may reflect Apple’s historical usage of disk images, which have been most commonly used for reading rather than writing. However, that has now changed, with write performance becoming important to the user in:

  • encrypted disk images used as a substitute for the absence of folder encryption in APFS;
  • both encrypted and unencrypted sparse bundles used for shared Time Machine backup storage;
  • unencrypted disk images used as Block Device storage in virtualisation.


  • All types of Disk Image have severely degraded write performance.
  • Write performance of encrypted disk images is absurdly bad.
  • Until Apple improves this substantially, Disk Images of any type can’t be recommended for writing, and are only suitable as read-only storage.
  • Apple boasts that the SSD in a Mac Studio M1 Max “delivers up to 7.4GB/s of performance”, and it has “up to 50 percent faster CPU performance than Mac Pro with a 16-core Xeon processor”. Then why does it write to an encrypted disk image at only 57 MB/s, the speed of a slow hard disk?