On Fri, Oct 15, 2021, 3:55 PM Alexander Kanavin <alex.kana...@gmail.com> wrote:
> On Fri, 15 Oct 2021 at 19:29, Richard Purdie < > richard.pur...@linuxfoundation.org> wrote: > >> >> Can you quantify "more"? >> >> I'd be interested to know if a higher compression helps and what the >> time/cost >> tradeoff is too. Not sure I'm keep to have it increase in size. This >> likely >> increases the eSDK size a lot too? >> > > The benefit is indeed not unquestionable, hence the RFC. > > 1. The eSDK is mostly made of already compressed sstate artifacts, so the > effect on size is minimal and the zstd's time benefit is clear: > > $ bitbake -c populate_sdk_ext core-image-sato (to have everything ready) > $ bitbake -c cleansstate core-image-sato buildtools-tarball > $ time bitbake -c populate_sdk_ext core-image-sato > > xz time/size > 4m46s 1.7G > > zstd compression level/time/size > 19 3m4s 1.7G > 10 2m44s 1.8G > > 2. For the basic SDK (bitbake commands are similar), xz's better (but > slower) compression does show clearly, but zstd's time wins are similar : > > xz time/size > 5m20s 581M > > zstd compression level/time/size: > 19 4m5s 837M > 15 3m44s 979M > 10 3m22s 993M > default(3) 3m19s 1.1G > Is this the maximum compression level for zstd? Also, are any of these using parallel compression? > Alex > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157018): https://lists.openembedded.org/g/openembedded-core/message/157018 Mute This Topic: https://lists.openembedded.org/mt/86353954/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
