Save Time & Energy with libcompression

In iOS 9 and macOS 10.11 Apple introduced the libcompression APIs to provide a more standard way of compressing and decompressing data in your apps while offering a selection of algorithms with tradeoffs between compression efficiency, time, and energy requirements. In the past I’ve used third party APIs to compress or decompress ZIP archives given the popularity of the format, but hadn’t considered using other algorithms to either benefit from better compression or energy efficiency. Given that, I decided to take a look at the algorithms offered by libcompression and see how they compare.

The Data Compression documentation describes the available algorithms as:

• LZFSE – A proprietary algorithm developed by Apple, designed to match the compression performance of ZLIB level 5, although with a 2–3x performance (time & energy) advantage.
• LZ4 – An Apple optimized version of this high performance open source compressor.
• LZMA – A LZMA implementation with excellent level 6 encoding and decoding of any level.
• ZLIB – A ZLIB implementation with level 5 encoding and decoding of any level designed to offer a balance between compression ratio and speed.

To informally test these algorithms I put together an iOS app using Apple’s CompressionSample source code, using the code to compress a 57MB TAR archive 5 times with each of the algorithms. It’s not a exactly a scientific test, but should give us an idea of how the different algorithms perform with respect to compression ratio and time / energy. All tests were run on an iPhone 7 running iOS 10.2.1.

File Size

When looking at compression ratio, the LZMA algorithm outperformed the other options by compressing the original 56.7MB file to 31.9MB. LZFSE, ZLIB, and ZIP all achieved 35MB, while LZ4 resulted in a 39.7MB file. For comparison I’ve included a copy of the TAR archive when compressed with ZIP using the macOS Finder. It’s good to see that LZFSE, as advertised, achieves pretty much the same compression ratio as ZLIB.

Time & Energy

While the file size comparison provides some initial insights, the time / energy comparison is far more interesting. The compression ratio advantage offered by LZMA is far outweighed by the time / energy efficiency of the other algorithms. It’s a whopping 136 times slower and uses far more energy than LZ4! The LZ4 compressor completes the tasks in an impressive 1.34 seconds, far less than I expected.

Interestingly, Apple’s LZFSE algorithm completes the task in 4.76 seconds compared to 10.24 with ZLIB, the expected difference of about 2x.

This difference is illustrated in the gallery below comparing the Foreground App CPU activity as measured by Instruments while the app is running on the iPhone 7. You can see that the CPU usage by LZ4 and LZFSE, while intense, is brief. ZLIB has similar CPU usage, but for a longer period of time. Finally, LZMA pegs the CPU at close to 100% for far longer, using much more energy in the process.

Conclusions

Obviously this is only a single test but based on the results it may be worth considering using compression to reduce the size of some of your application resources or data files if you’re not already, or switching algorithms if you are. Whether running on an A-series CPU in an iOS based device or on a Mac laptop, being respectful of the user’s battery life and energy usage is becoming increasingly important. Given it’s compression, performance, and energy characteristics LZFSE looks to be a great solution to help achieve those goals. If it’s not in your case, and you’re currently using a third party library, consider some of the other algorithms in libcompression given that some of them are optimized for Apple’s hardware and you may be able to see some other gains.

Other LZFSE Resources

For more details about libcompression and LZFSE, take a look at WWDC 2015 Session 712 along with Apple’s reference implementation on GitHub.

Header image via James Mackintosh, licensed under Creative Commons.