> 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?
> 

Interesting idea. What OS did you use? I tried this on macOS on some larger FVs and I did not see much difference? I tried a 17.5 MiB FV and it was around 3 seconds both ways. 

Maybe it would be worth while seeing how it works on various systems? I guess it might be data set related? 

Thanks,

Andrew Fish

> Thanks,
> Daniel
> 
> 
>