Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce darling's impact on build time #237

Open
TedDriggs opened this issue May 24, 2023 · 1 comment
Open

Reduce darling's impact on build time #237

TedDriggs opened this issue May 24, 2023 · 1 comment

Comments

@TedDriggs
Copy link
Owner

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.

darling build timings

Here is the stderr output of running RUSTFLAGS="-Z time-passes" cargo +nightly build.

@daxpedda
Copy link

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.

Matklad made an excellent blog post about this topic: https://matklad.github.io/2021/09/04/fast-rust-builds.html.
The blog post also dives into monomorphization and how it can significantly impact your build times.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants