| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
This adjusts our compression settings for xz compressed files, which
should reduce download sizes by around 5-15%, at the cost of ~44% longer
compression times. Given that compression happens almost universally in
CI, rather than something humans are directly waiting for, this tradeoff
feels worth it.
If we end up seeing this be too significant an increase in CI times,
moving the more aggressive compression solely to promote-release should
be relatively straightforward and give most of the benefits.
|
| |
|
|
|
|
|
|
|
|
| |
Currently, the order of the entries in `manifest.in` depends on the
iteration order of `copy_with_callback`, which in turn depends on
`WalkDir`, which explicitly says iteration order is unspecified. It's
possible to call `WalkDir::sort_by` to give an iteration order for each
directory's entries, but it felt better to accumulate the lines and then
sort them to a) make it more evident that this is happening, and b)
enable the copying to be parallelized in the future.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At preset 6, xz2 uses about 173MB of memory per thread. This adds up
quickly -- e.g. over 8GB of memory on a 48-CPU machine. If you happen to
try this in a 32-bit build, you'll get `LZMA_MEM_ERROR`.
We can limit this to a heuristic maximum number of threads to avoid
using so much memory, like xz's [`04_compress_easy_mt` example].
// The number 8 is arbitrarily chosen and may be too low or
// high depending on the compression preset and the computer
// being used.
[`04_compress_easy_mt` example]: https://github.com/xz-mirror/xz/blob/de1f47b2b40e960b7bc3acba754f66dd19705921/doc/examples/04_compress_easy_mt.c#L71
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
lldb includes some symlinks in its install tree, and so generator must
copy these symlinks as well. I believe only file symlinks are needed.
|
| |
|
|
|
| |
The lldb repository has a symlink in it, and so for the tarballer to
work when lldb is included, it must not follow symlinks.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Creating tarballs seems to be taking ridiculous amounts of time on the dist bots
(upwards of 10-20 minutes) and we're not *that* small anyway so let's shave off
some build time by turning down the compression level a bit.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This melds the serial-`Tee` and parallel-batched approaches from before
and after commit adea17e. Now we can get the same multithreaded speedup
without having to build the entire uncompressed tarball in memory first.
The new `impl Write for RayonTee` uses `rayon::join` to split the
compression work for each buffer to separate threads. This is scoped,
so it can be fully zero-copy, sharing the input buffer directly. This
is all wrapped in a 1 MiB `BufWriter` to balance the cost of thread
wake-ups and synchronization.
The net performance is unchanged, using around 125% CPU -- approximately
4:1 time spent in xz versus gz. The overall memory use is much reduced,
now independent of the tarball size -- just a few MiB on top of the
fixed-cost 674 MiB compressor memory requirements of `xz -9`.
|
| |
|
|
| |
Unblocks rust-lang/rust#46278.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Since Windows doesn't really have Posix file modes, the tar crate only
sets file modes based on whether the source is readonly. But we do want
stuff like `install.sh` to be executable when extracted elsewhere.
Now we create a manual header for our files, and add the executable bit
on files matching whitelisted extensions (exe, dll, py, sh). That's not
trying to be exhaustive or perfect, but it's hopefully good enough to
have functional rust packages.
|
| |
|
|
| |
Fixes #65
|
| |
|
|
|
|
|
|
| |
This reverts commit 4f6e020b179ef79a3e3717f80132ad1a4875a669.
We need to leave the unpacked input packages intact for rustbuild to
reuse in OS-specific installers on macOS and Windows. Add a test to
make sure the components are still present.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|