cargo-bisect-rustc
measureme
cargo-bisect-rustc | measureme | |
---|---|---|
4 | 2 | |
173 | 326 | |
1.7% | 2.5% | |
7.8 | 7.0 | |
10 days ago | 5 days ago | |
Rust | Rust | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
cargo-bisect-rustc
-
Goodbye to the C++ Implementation of Zig
> One big downside is losing the ability to build any commit from source without meta-complexity creeping in. For example, let’s say that you are trying to do git bisect. At some point, git checks out an older commit, but the script fails to build from source because the binary that is being used to build the compiler is now the wrong version. Sure, this can be addressed, but this introduces unwanted complexity that contributors would rather not deal with.
If it's the main concern of using a prior build of the compiler, an alternative solution is to develop a tool for contributors to automate and ease the process. For example, Rust has this: https://github.com/rust-lang/cargo-bisect-rustc
-
Cross v0.2.2 Released
Added support for tools like cargo-bisect-rustc.
- Why does my code compile faster on nightly?
-
1.56 Compile time is through the roof!?
Finally, https://github.com/rust-lang/cargo-bisect-rustc/blob/master/TUTORIAL.md can bisect Nightlies or (if recent enough, I think CI artifacts are kept 3 months) PRs to tell you one introduced a problem.
measureme
-
1.56 Compile time is through the roof!?
To dig further into one specific rustc process called by Cargo, cargo +nightly rustc -- -Z self-profile -p some_crate https://github.com/rust-lang/measureme/blob/master/summarize/README.md
-
Reducing Rust Incremental Compilation Times on macOS by 70%
> When does the Rust compiler spend most of it's time? Is it at the checking stage?
rustc has a self-profiler that can be used to answer this question [0], as well as a mode that times each compiler pass [1].
There's no single reason the Rust compiler is slow, as it depends quite heavily on the code being compiled. For some codebases, LLVM code takes up most of the time; in other codebases (e.g., extremely generic-heavy codebases), it'll be checking-related passes.
[0]: https://github.com/rust-lang/measureme/blob/master/summarize...
[1]: https://wiki.alopex.li/WhereRustcSpendsItsTime
What are some alternatives?
zvm - zvm (Zig Version Manager) lets you easily install/upgrade between different versions of Zig.
cargo-llvm-lines - Count lines of LLVM IR per generic function
cargo-udeps - Find unused dependencies in Cargo.toml
live-bootstrap - Use of a Linux initramfs to fully automate the bootstrapping process
arewefastyet - arewefastyet.rs - benchmarking the Rust compiler
rust - Rust for the xtensa architecture. Built in targets for the ESP32 and ESP8266
nix-zig-stdenv - cross-compile nixpkgs with zig
cross - “Zero setup” cross compilation and “cross testing” of Rust crates
rust - Empowering everyone to build reliable and efficient software.
mold - Mold: A Modern Linker 🦠
stage0 - A set of minimal dependency bootstrap binaries