measureme
cargo-llvm-lines
Our great sponsors
| measureme | cargo-llvm-lines | |
|---|---|---|
| 2 | 3 | |
| 323 | 372 | |
| 1.9% | - | |
| 7.2 | 7.3 | |
| about 2 months ago | 24 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.
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
cargo-llvm-lines
-
Making a Rust crate compile faster [video]
This is a livestream, the "offline" artefact is a function of that but not the primary one. Jon essentially uses livestreams as exploratory labs / presentations, and even ignoring the regular Q&As audience interaction is both common and commonly useful there — for instance in this one /u/dtolnay suggests something about cargo-llvm-lines as Jon is working with it.
-
1.56 Compile time is through the roof!?
If you want to dig further, I see though that some of this time is spent in codegen (generating LLVM IR) and in LLVM. Maybe something is generating much more IR than before, which then takes a lot of time to process. Another tool is https://github.com/dtolnay/cargo-llvm-lines which shows the number of lines of unoptimized LLVM IR for each of your functions. In general it can be useful to optimize compile times of your project, in this case it might show which area of your code triggers this bug.
-
David Tolnay - thank you
cargo llvm-lines, too.
What are some alternatives?
cargo-udeps - Find unused dependencies in Cargo.toml
rust-quiz - Medium to hard Rust questions with explanations
arewefastyet - arewefastyet.rs - benchmarking the Rust compiler
semver-trick - How to avoid complicated coordinated upgrades
cargo-bisect-rustc - Bisects rustc, either nightlies or CI artifacts
async-trait - Type erasure for async trait methods
axum - Ergonomic and modular web framework built with Tokio, Tower, and Hyper
db-dump - Library for scripting analyses against crates.io's database dumps
rust - Empowering everyone to build reliable and efficient software.