[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: When substitute download + decompression is CPU-bound
From: |
Jonathan Brielmaier |
Subject: |
Re: When substitute download + decompression is CPU-bound |
Date: |
Tue, 15 Dec 2020 11:40:10 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Icedove/78.5.1 |
Super interesting findings!
On 14.12.20 23:20, Ludovic Courtès wrote:
2. Use Zstd like all the cool kids since it seems to have a much
higher decompression speed: <https://facebook.github.io/zstd/>.
630 MB/s on ungoogled-chromium on my laptop. Woow.
Not only decompression speed is fast, compression is as well:
size file time for compression (lower is better)
335M uc.nar
104M uc.nar.gz
8
71M uc.nar.lz.level9 120
74M uc.nar.lz.level6
80
82M uc.nar.lz.level3 30
89M uc.nar.lz
.level1 16
97M uc.nar.zst 1
So I am bought by zstd, as user and as substitution server care taker :)
For mobile users and users without internet flatrates the increased nar
size is a problem.
Although I think the problem here is not bewtween gzip, lzip and zstd.
It's the fact that we completely download the new package even if's just
some 100 lines of diffoscope diff[0]. And most of them is due to the
change /gnu/store name...
[0] diffoscope --max-diff-block-lines 0
/gnu/store/zvcn2r352wxnmq7jayz5myg23gh9s17q-icedove-78.5.1
/gnu/store/dzjym6y7b9z4apgvvydj9lf0kbaa8qbv-icedove-78.5.1
lines: 783
size: 64k
Re: When substitute download + decompression is CPU-bound, Ludovic Courtès, 2020/12/15
Re: When substitute download + decompression is CPU-bound,
Jonathan Brielmaier <=