On Fri, 2021-10-15 at 22:54 +0200, Alexander Kanavin wrote: > On Fri, 15 Oct 2021 at 19:29, Richard Purdie > <[email protected]> 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.
Thanks, I think we need data to be able to comment effectively! :) > 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 For the eSDK this looks like an ok change. > 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 but nearly doubling the size of the standard SDK isn't going to be well received by people using it, those numbers don't look like they can work even if it is faster. The key things are primarily size and secondly decompression time, compression time is in third place and unfortunate but something the build systems can afford to pay. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157012): https://lists.openembedded.org/g/openembedded-core/message/157012 Mute This Topic: https://lists.openembedded.org/mt/86353954/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
