On Dec 1, 2020, at 6:59 PM, Daniel Schaefer <daniel.schaefer@hpe.com> wrote:

Hi everyone,

I'm looking into how to speed up the build process and noticed that our build
uses LZMA to encrypt the main firmware volume. Since it's quite big it takes a
while but only uses one CPU thread.

LZMA2 is a version of LZMA which can be multi-threaded and achieve much faster
compression times. I did a quick benchmark using the `xz` command-line tool,
which uses a modified version of the LZMA SDK that EDK2 uses. The results are:

Uncompressed size: 64M

| Algo  | Comp Time | Decomp Time | Size | Threads |
| ----- | --------- | ----------- | ---- | ------- |
| LZMA  |    19.67s |        0.9s | 9.1M |       1 |
| LZMA2 |    20.11s |        1.2s | 9.2M |       1 |
| LZMA2 |     8.31s |        1.0s | 9.4M |       4 |

Using those commands:

time xz --format=lzma testfile
time unlzma testfile.lzma

time xz --lzma2 testfile
time unxz testfile.xz

time xz -T4 --lzma2 testfile
time unxz testfile.xz

This is quite a significant improvement of build time, while decompression time
and size only slightly increase. If that's a concern, then LZMA2 could be used
for development only.

I haven't investigated the details of how to support this in the code but it
appears to be a simple change, since the LZMA SDK that we use already supports
LZMA2.

What do you think?

Thanks,
Daniel