Clean up "performance allocators" and "performance flate2" backends#7686
Merged
Clean up "performance allocators" and "performance flate2" backends#7686
Conversation
Instead of having conditional cargo dependencies in both uv-dev and uv, and different `--features` invocations in CI, this introduces a series of `uv-performance-*` crates that do the right thing. These are enabled by default, but can be disabled when working on correctness alone, locally.
BurntSushi
approved these changes
Sep 25, 2024
Contributor
|
Windows CI is being flaky again :( |
konstin
added a commit
that referenced
this pull request
May 2, 2025
#5577 fixed a bug on macos due to dynamically linking lzma/xz through static linking. In #7686, this feature was moved to the performance category. This PR moves the `xz2/static` back to the general default features, and, inspired by Homebrew/homebrew-core#222211, it structures and documents the feature flags cleaner
zanieb
added a commit
that referenced
this pull request
May 2, 2025
#5577 fixed a bug on macos due to dynamically linking lzma/xz through static linking. In #7686, this feature was moved to the performance category. This PR moves the `xz2/static` back to the general default features, and, inspired by Homebrew/homebrew-core#222211, it structures and documents the feature flags cleaner. We need to take care that this feature does not accidentally disable features we want. --------- Co-authored-by: Zanie Blue <contact@zanie.dev>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rebased version of #7000, description copied below.
Closes #7000
Summary
@charliermarsh has long suspected local builds could be made faster by disabling things like: tikv-jemalloc/mimalloc, zlibng etc.
I'm going through the cargo dep tree looking at things that can be disabled locally.
Methodology:
productioncargo flag enables all the production stuff (good allocators, fast compression libs, etc.)I measure fresh
cargo checkruns, like so:rm -rf /tmp/timings; CARGO_TARGET_DIR=/tmp/timings cargo check -F production-memory-allocator --timingsVarying the
-Fto enable/disable the featuresFAQ
Q: Why only check
check?A: The benefits will trickle down to other subcommands (including test/nextest etc.) — check/clippy are super common while iterating. We can do larger checks near the end.
Q: Why only check cold builds?
A: Warm builds depend on a lot on which part of the code is touched — I'll optimize typical interactions later on.