Skip to content
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

Don't gzip staging tarballs. #45515

Merged
merged 1 commit into from
May 31, 2022
Merged

Don't gzip staging tarballs. #45515

merged 1 commit into from
May 31, 2022

Conversation

maleadt
Copy link
Member

@maleadt maleadt commented May 30, 2022

Creating the staging tarballs takes a significant portion of the time spent compiling Julia with LLVM from source. It seems a little redundant that we're doing this in the first place -- can't we just run make install again? -- but @vtjnash has said it improves atomicity, so... But at least we shouldn't be gzipping these tarballs as they compress very badly, and just using tar is way faster.

@maleadt maleadt added the domain:building Build system, or building Julia or its dependencies label May 30, 2022
@maleadt maleadt requested a review from vtjnash May 30, 2022 10:54
@oscardssmith oscardssmith merged commit 0fce312 into master May 31, 2022
@oscardssmith oscardssmith deleted the tb/staging_tarball branch May 31, 2022 15:46
@vtjnash
Copy link
Sponsor Member

vtjnash commented May 31, 2022

They usually don't implement a good make uninstall, which is what we need. This sounds good, though I would be curious if we could get zstd working here now too, which is supposed to basically just make the I/O faster.

@maleadt
Copy link
Member Author

maleadt commented Jun 2, 2022

On my M1 with an NVME, a 4GB LLVM debug build takes:

  • 0.2s to tar -cf /dev/null
  • 2.3s to tar -cf llvm.tar
  • 87s (!) to tar -czf, generating 885M of output
  • 6.6s to tar | zstd --fast, generating 1G of output
  • 3.3s to tar | zstd --fast --threads=8
  • 3.7s to tar | zstd --threads=8, generating 866MB of output

So even though zstd doesn't 'just' reduce I/O time by compressing faster than I can write my NVME, the tradeoff seems very much worth it, spending a couple of seconds to reduce storage a lot!

How do we want to depend on zstd, just add it as a required build dep, autodetect its availability, or is there a way to use it from JLLs in our Makefiles?

@oscardssmith
Copy link
Member

since zstd and gzip produce such similar sizes, it might be worth trying lz4

@vtjnash
Copy link
Sponsor Member

vtjnash commented Jun 2, 2022

We could switch BinaryBuilder over to it, then it would have to be available

@maleadt
Copy link
Member Author

maleadt commented Jun 2, 2022

since zstd and gzip produce such similar sizes, it might be worth trying lz4

lz4 is both slower, does not support multithreading, and compresses my LLVM debug folder worse.

@staticfloat
Copy link
Sponsor Member

We have https://github.com/JuliaBinaryWrappers/Zstd_jll.jl available. To get it during the build process, you need to basically do the same thing that we do with p7zip:

  • Add an entry in deps/Versions.mk just like we have for p7zip. This sets the source version downloaded. To set the JLL version, you need to define ZSTD_JLL_VER. If we were shipping this JLL with Julia as a stdlib, we would parse it out of the stdlib/zstd_jll/Project.toml, but since we don't have one of those, we define it in this .mk file.
  • Add a deps/zstd.mk, just copy deps/p7zip.mk.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:building Build system, or building Julia or its dependencies
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants