Daniel: Can you provide the compressed image size? And, what image is used to be compressed? Is it the generated FV image? Thanks Liming 发件人: bounce+27952+68159+4905953+8761045@groups.io 代表 Andrew Fish via groups.io 发送时间: 2020年12月2日 11:37 收件人: devel@edk2.groups.io; daniel.schaefer@hpe.com 抄送: derek.lin2@hpe.com 主题: Re: [edk2-devel] Multithreaded compression with LZMA2 On Dec 1, 2020, at 6:59 PM, Daniel Schaefer > 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