I like this, only, what are compilation times going to be like?

▲ echelon 3 days ago | parent [-]

I'm really starting to hate on Rust macros due to the compilation times. The core language is fine, but macros are the mind killer.

We're progressively banning macro usage from our Rust monorepo. Macro-heavy dependencies are also going to be pruned eventually.

As much as I love Serde, it makes compile times for projects like async-stripe absolutely productivity killing. It interferes heavily with work.

Crates.io would be fantastic if it had compile time metrics and macro metrics reported for projects and dependencies.

▲ zamalek 2 days ago | parent | next [-]

I have tried setting the build dependencies optimization level to higher-than-default in the past, but it seems to achieve nothing.

    [profile.dev.build-override]
    opt-level = 3
    codegen-units = 1
    
    [profile.dev.package."syn"]
    opt-level = 3
    codegen-units = 1
    
    [profile.dev.package."synstructure"]
    opt-level = 3
    codegen-units = 1
    
    [profile.dev.package."quote"]
    opt-level = 3
    codegen-units = 1

    # CTRL+C when it reaches async-stripe, then repeat
    > rm -r target/debug/build/async-stripe*; time cargo build

default, O1, O2, O3:

    Executed in   47.13 secs
    Executed in   45.68 secs
    Executed in   46.07 secs
    Executed in   46.22 secs

sccache will provide a major benefit, especially in combination with `cargo-hakari`.

▲ huhlig 2 days ago | parent | prev [-]

I guess it depends on which is more important to you. The compile time cost and runtime savings of compile time reflection, or the compile time savings and runtime cost of runtime reflection. You're going to pay the fee one way or another. I personally prefer compile-time cost as I pay it once.

▲

jtwaleson 2 days ago | parent [-]

I understand what you mean but "pay it once" is the wrong description for something that you do hundreds/thousands of times per day as a developer. Every time I save a file in my IDE, the Rust checkers run and are very slow.

▲

zamalek 2 days ago | parent [-]

Make sure you tell rust-analyzer to use its own profile (<init_options>.rust.analyzerTargetDir=true).

This means rust analyzer and your IDE will have different target dirs (target/debug and target/rust-analyzer), this can prevent flagging resulting from cargo and rust-analyzer fighting over the features etc. I have this set at system/global level in my IDE config. The downside is that you'll use double the disk space.

	▲	jtwaleson a day ago \| parent [-]
		Omg, I've been thinking about how to achieve this. Feel a bit stupid reading it's a standard option.. Thanks! Since earlier this year I've upgraded my hardware, I'm on the wild linker, the Cranelift backend and I've switched from cargo clippy to cargo check for the rust analyzer (with clippy running under a shortkey and as pre-commit). I have a backend and frontend for my project, and the typescript frontend with its sub-second feedback cycle definitely helps for staying in a flow-state. With all of the improvements above, rust is still at 3 to 10 seconds.