-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explore options on zstd for compression performance #642
Comments
I explored various flag of zstd like fast, adapt, ultra and tried different levels. The size vs time trade off is not worth to switch zstd as default . |
@ashleshaAtrey I'm interested in if you still have those numbers around. It might be something that is worth exposing as a configuration option to the user. Some may find the trade-off to be worth it depending on the particular content that they are providing as eventually this would be used by 3rd-party bundles as well. |
@bryteise It is already exposed. You can use it by setting |
Total size before compression 43184317440 zstd --fast=22 Zstd --adapt Zstd --fast Zstd --ultra |
Do you have the numbers for the other compression methods as well (xz, bzip2, gzip)? |
Xz: bzip2 gzip |
I think that decompression speed is also worth cross-comparing, because xz tends to be slower than zstd in this area, and swupd has to decompress many files in course of its operation. |
Also note Arjan's old blog post where he conducted a detailed cross-comparison for compression types. It would be awesome to produce a followup to that post with the latest findings. |
I ran decompression tests on 906752 fullfiles using the tar utility, For XZ compression, time took to decompress: 11134 seconds Next, I will work on finding the stats for memory used while compressing and decompressing those files. |
Memory used while creating fullfiles: Zstd compression |
Interesting zstd is taking longer to decompress (and by a fairly significant amount too). That's really surprising. |
@ashleshaAtrey Can you review if the numbers and units look correct.
|
I am very surprised to see |
Thinking about this a little more. I wonder if there is a set of files which take disproportionately longer to decompress (but there are few of them) or files that take slightly longer to decompress (but there are many of them)? Figuring this out would be enlightening. Do you have file by file time differences? |
I will work on finding file by file time difference, dont have those stats handy. |
Either from a CPU or memory perspective, let's explore if using the options for zstd affects compression performance to see if it can get better than xz by a degree enough to switch to zstd by default.
The text was updated successfully, but these errors were encountered: