LZFSE Disk Images in El Capitan
One of my favorite improvements in El Capitan is the new LZFSE compression algorithm, which is available directly to apps as well as via a new disk image format. The new .dmg format is not accessible in Disk Utility, but I’ve added support for it in DropDMG 3.2.8. Here are some benchmarks I made imaging a 11.28 GB boot partition on a MacBook Air.
| Method | Size | Savings | Throughput |
|---|---|---|---|
| zlib (10.10) | 8.86 GB | 21.4% | 63.5 MB/sec |
| zlib (10.11) | 8.75 GB | 22.3% | 36.8 MB/sec |
| LZFSE (10.11) | 8.60 GB | 23.8% | 107.7 MB/sec |
| bzip2 (10.11) | 7.03 GB* | 23.2% | 11.7 MB/sec |
| none (10.11) | 9.15 GB* | 0% | 114.4 MB/sec |
The source and destination partitions were on the same SSD, and both were encrypted with FileVault 2. I’m impressed that the Air can decrypt, compress, and encrypt to the same drive at more than 100 MB/sec. In 1996, I measured copy throughput at just 43K/sec.
The bottom line is that LZFSE is both faster than zlib and compresses more tightly. (It is supposed to decompress faster as well.) Apple has also tweaked the way zlib is used so that disk images created on 10.11 are smaller than those created on 10.10 (but are slower to create). The smaller zlib disk images are still backwards compatible with previous OS versions, whereas the LZFSE disk images can only be opened on 10.11 or later.
Lastly, the redesigned Disk Utility has removed the feature for burning disk images. The help claims that you can do this with the Finder, but I think that feature has also been removed. You can still burn files and disk images with DropDMG.
Update (2015-10-07): The Burn command is still in the Finder, but now it’s only shown if a burner is connected.
I added results for bzip2 and none (no compression). The destination sizes say * because I no longer have the exact same volume (an El Capitan beta) to test with; I instead imaged a fresh El Capitan installation, which had a different source size (9.15 GB) but should be a similar mix of files. These new results show that bzip2 is really slow, which was common knowledge. More interestingly, no compression was not much faster than LZFSE (which makes sense given LZFSE’s goals), and bzip2 was actually worse at compressing than LZFSE (unexpected).
4 Comments RSS · Twitter
"LZFSE is only present in iOS and OS X, so it can’t be used when the compressed payload has to be shared to other platforms (Linux, Windows). In all other cases, LZFSE is recommended as a replacement for ZLIB."
A proprietary compression, not that exciting really, as I can't really come up with too many "other cases".
bzip2 uses Huffman (instead of FSE) which doesn't handle skewed probability distributions - it is probably the reason of weaker compression.
While LZFSE is a propriety software, ZSTD is an open source LZ+FSE: https://github.com/Cyan4973/zstd
Your test file is nearly incompressible.
Better use a more typical compressible file where the savings are from 80% to 65%.
