You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
darling's impact on build times is cited as a reason not to use it for parsing the #[wasm_bindgen] macro in [this comment]. darling should try to be a "zero-cost abstraction" for those who use it, which includes minimizing build time impacts from its usage.
Goals/Parameters
1. Minimize build time over using syn with the same features darling needs.
Since syn is the de facto standard for Rust parsing, counting it in darling's build times doesn't make sense; long syn build times should not count against darling, and improvements in syn's build time should not count as progress for darling.
2. Don't make crate authors choose between build times and customer-facing functionality
This project should first look for improvements that are invisible to users of darling, before exploring any cargo features for reducing build time. However, if/when we do explore those, we should minimize flags that impact the experience of developers who are using crates that rely on darling.
The suggestions feature appears to be an example of what not to do here, but in reality that feature was introduced because strsim had a higher MSRV than darling at the time of the feature's introduction.
Current Timings
Here is the output of cargo clean && cargo build --release --timings; remove the .txt extension and then locally open the file to see the results.
Here is the stderr output of running RUSTFLAGS="-Z time-passes" cargo +nightly build.
The text was updated successfully, but these errors were encountered:
Unfortunately there isn't much to read into this @TedDriggs, as far as i know.
Basically blue means building and purple means code generation, like macros and proc macros, which means that some dependencies can start compiling even though their dependencies are still generating code.
The usual things to do in cases like this is to split your crates into parts that can more easily be gated behind features and enabled as necessary. Very carefully auditing your dependencies and the features you enable on them might also reveal some easy gains.
darling
's impact on build times is cited as a reason not to use it for parsing the#[wasm_bindgen]
macro in [this comment].darling
should try to be a "zero-cost abstraction" for those who use it, which includes minimizing build time impacts from its usage.Goals/Parameters
1. Minimize build time over using
syn
with the same featuresdarling
needs.Since
syn
is the de facto standard for Rust parsing, counting it indarling
's build times doesn't make sense; longsyn
build times should not count againstdarling
, and improvements insyn
's build time should not count as progress fordarling
.2. Don't make crate authors choose between build times and customer-facing functionality
This project should first look for improvements that are invisible to users of darling, before exploring any cargo features for reducing build time. However, if/when we do explore those, we should minimize flags that impact the experience of developers who are using crates that rely on
darling
.The
suggestions
feature appears to be an example of what not to do here, but in reality that feature was introduced becausestrsim
had a higher MSRV thandarling
at the time of the feature's introduction.Current Timings
Here is the output of
cargo clean && cargo build --release --timings
; remove the.txt
extension and then locally open the file to see the results.Here is the stderr output of running
RUSTFLAGS="-Z time-passes" cargo +nightly build
.The text was updated successfully, but these errors were encountered: