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 Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157009): https://lists.openembedded.org/g/openembedded-core/message/157009 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] -=-=-=-=-=-=-=-=-=-=-=-
