[edk2-devel] Multithreaded compression with LZMA2

Bret Barkelew via groups.io bret.barkelew=microsoft.com at groups.io
Thu Dec 3 15:57:41 UTC 2020


Wasn’t there another push (somewhere in the last 8 months, my brain is foggy) to adopt LZMA2? Or was it a different algorithm?

- Bret

From: Daniel Schaefer via groups.io<mailto:daniel.schaefer=hpe.com at groups.io>
Sent: Thursday, December 3, 2020 4:12 AM
To: Laszlo Ersek<mailto:lersek at redhat.com>; devel at edk2.groups.io<mailto:devel at edk2.groups.io>
Cc: Lin, Derek (HPS SW)<mailto:derek.lin2 at hpe.com>
Subject: [EXTERNAL] Re: [edk2-devel] Multithreaded compression with LZMA2


From: Laszlo Ersek <lersek at redhat.com>
Sent: Thursday, December 3, 2020 18:24
To: devel at edk2.groups.io <devel at edk2.groups.io>; Schaefer, Daniel <daniel.schaefer at hpe.com>
Cc: Lin, Derek (HPS SW) <derek.lin2 at hpe.com>
Subject: Re: [edk2-devel] Multithreaded compression with LZMA2

On 12/02/20 03:59, 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?

"xz -T" works by splitting the input into blocks, and it generates a
multi-block compressed output.

Yes, that's correct.

> I'm unsure if the current LZMA
decompressor that runs inside the firmware (= guided section extractor)
copes with multi-block input.

I think you're right that it doesn't. But we can make the guided section extractor use that same algorithm(LZMA2) and assign it a different GUID, right?




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#68254): https://edk2.groups.io/g/devel/message/68254
Mute This Topic: https://groups.io/mt/78651832/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20201203/d7bc1e68/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 69F4FCEBBB92465AA3A93438CD55E1D3.png
Type: image/png
Size: 140 bytes
Desc: 69F4FCEBBB92465AA3A93438CD55E1D3.png
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20201203/d7bc1e68/attachment.png>


More information about the edk2-devel-archive mailing list