Compile / typecheck perf regression in 0.16 from proc macro changes

[h3r2tic]

Bevy version

• Original: 669d139
• Current: 1b7db89

Relevant system information

cargo --version
cargo 1.85.0 (d73d2caf9 2024-12-31)
uname -a
Linux h3-arch 6.12.10-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 18 Jan 2025 02:26:57 +0000 x86_64 GNU/Linux

What's performing poorly?

Howdy! I've upgraded Tiny Glade's Bevy deps to 0.16.0-dev to play around with auto-registration of reflection info, and I've noticed Rust Analyzer being sluggish. The Rust Analyzer slowdown is also reflected in running build/check/clippy. I've bisected it down to #17330

The test I'm doing is touching/modifying a single .rs file in our chonkiest crate The numbers are best out of a few runs.

Using bevy at commit 669d139:

• Rust Analyzer build (running clippy) after a ctrl+s: 6.53s
• cargo clippy: 5.36s
• cargo check: 1.98s
• cargo build (touch one .rs file, no change): 3.03s
• cargo build: (modify one function) 4.39s

Using bevy at commit 1b7db89:

• Rust Analyzer build (running clippy) after a ctrl+s: 12.40s
• cargo clippy: 11.19s
• cargo check: 7.83s
• cargo build (touch one .rs file, no change): 8.78s
• cargo build (modify one function): 10.18s

Before and After Traces

Traces for touching a single .rs file and running cargo build --timings

• Before: https://jsfiddle.net/fgyhduwn/
• After: https://jsfiddle.net/Lv5sb6hr/

Additional information

Here's our Bevy dependencies:

bevy_app = "0.16.0-dev"
bevy_ecs = { version = "0.16.0-dev", features = ["multi_threaded", "serialize"] }
bevy_input = { version = "0.16.0-dev", features = ["serialize"] }
bevy_log = "0.16.0-dev"
bevy_reflect = { version = "0.16.0-dev" }
bevy_state = { version = "0.16.0-dev", default-features = false, features = ["bevy_app", "bevy_reflect"] }
bevy_tasks = "0.16.0-dev"
bevy_time = { version = "0.16.0-dev", default-features = false }

[aloucks]

I've been struggling with this for a while now, but wasn't sure if it was a rust-analzyer problem or a bevy problem. It's been painfully slow for me (around a minute per cargo check after edits in some cases). I'm not sure how or why it impacts examples but they also seem to trigger full re-check after this change.

669d139
crates/bevy_ecs/lib.rs # add whitespace change

cargo check
Finished `dev` profile [unoptimized + debuginfo] target(s) in 14.26s

main
crates/bevy_ecs/lib.rs # add whitespace change

cargo check
Finished `dev` profile [unoptimized + debuginfo] target(s) in 48.51s

[Veykril]

Would be interesting to check how the numbers change with

[profile.dev.build-override]
opt-level = 3

set. That would force proc-macros and build scripts to be built with optimizations on. Given the bisection points to #17330 it might be that whatever that crate is doing is just very slow without in debug.

[aloucks]

Removing default-features = false from the bevy_* [dev-dependencies] made a huge improvement for me both from the command line and Rust-Analyzer. R-A is still doing something strange, but it's better overall.

$ git diff Cargo.toml
diff --git a/Cargo.toml b/Cargo.toml
index 7bd99fc3a..08ccaf6e3 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -504,14 +504,14 @@ flate2 = "1.0"
 serde = { version = "1", features = ["derive"] }
 serde_json = "1"
 bytemuck = "1.7"
-bevy_render = { path = "crates/bevy_render", version = "0.16.0-dev", default-features = false }
+bevy_render = { path = "crates/bevy_render", version = "0.16.0-dev" }
 # The following explicit dependencies are needed for proc macros to work inside of examples as they are part of the bevy crate itself.
-bevy_ecs = { path = "crates/bevy_ecs", version = "0.16.0-dev", default-features = false }
-bevy_state = { path = "crates/bevy_state", version = "0.16.0-dev", default-features = false }
-bevy_asset = { path = "crates/bevy_asset", version = "0.16.0-dev", default-features = false }
-bevy_reflect = { path = "crates/bevy_reflect", version = "0.16.0-dev", default-features = false }
-bevy_image = { path = "crates/bevy_image", version = "0.16.0-dev", default-features = false }
-bevy_gizmos = { path = "crates/bevy_gizmos", version = "0.16.0-dev", default-features = false }
+bevy_ecs = { path = "crates/bevy_ecs", version = "0.16.0-dev" }
+bevy_state = { path = "crates/bevy_state", version = "0.16.0-dev" }
+bevy_asset = { path = "crates/bevy_asset", version = "0.16.0-dev" }
+bevy_reflect = { path = "crates/bevy_reflect", version = "0.16.0-dev" }
+bevy_image = { path = "crates/bevy_image", version = "0.16.0-dev" }
+bevy_gizmos = { path = "crates/bevy_gizmos", version = "0.16.0-dev" }

[h3r2tic]

Thanks for the suggestions of stuff to try, and the tentative PR. So far, no luck - I observe the same check/RA durations with or without [profile.dev.build-override] opt-level = 3, and similarly with and without default-features = false.

FWIW, we don't use the bevy crate directly - I've listed our exact dependencies as an edit to the issue.

[cart]

Looking into this now. I have some suspicions.

[cart]

The crux of the issue appears to be: parsing the cargo manifest is expensive, and so is doing the work required to not parse the manifest every time. Naturally the best approach would be to stop parsing the manifest at all (which we do to determine whether our derive macros should use the bevy::ecs path or the bevy_ecs path).

In an ideal world, we could just do if cfg!(dependency = "bevy") {}, but that is not possible (at least, not yet).

I've found a solution, but it will involve more per-macro boilerplate (and dirtier module re-exports for the top-level bevy crate). The benefit is that at compile time, we naturally select the derive impl we need without any manifest parsing:

// in bevy_ecs/src/florp.rs
pub use bevy_ecs_macros::Florp;
pub use bevy_ecs_macros::FlorpBevy;
pub trait Florp {}

// in bevy_ecs/src/lib.rs
pub mod prelude {
    pub use crate::{
        florp::Florp
    }
}

// in bevy_ecs/macros/lib.rs
#[proc_macro_derive(Florp)]
pub fn derive_florp(input: TokenStream) -> TokenStream {
    derive_florp_internal(input, &bevy_macro_utils::try_parse_str("bevy_ecs").unwrap())
}

#[proc_macro_derive(FlorpBevy)]
pub fn derive_florp_bevy(input: TokenStream) -> TokenStream {
    derive_florp_internal(
        input,
        &bevy_macro_utils::try_parse_str("bevy::ecs").unwrap(),
    )
}

fn derive_florp_internal(input: TokenStream, bevy_ecs_path: &syn::Path) -> TokenStream {
    let ast = parse_macro_input!(input as DeriveInput);
    let name = ast.ident;
    let (impl_generics, ty_generics, where_clauses) = ast.generics.split_for_impl();

    TokenStream::from(quote! {
        impl #impl_generics #bevy_ecs_path::florp::Florp for #name #ty_generics #where_clauses {
        }
    })
}


// in bevy_internal
pub mod ecs {
    pub use bevy_ecs::*;
    pub mod prelude {
        pub use super::florp::FlorpBevy as Florp;
        pub use bevy_ecs::prelude::*;
    }

    pub mod florp {
        pub use bevy_ecs::florp::{FlorpBevy as Florp, *};
    }
}

[cart]

Also note that reverting #17330 would naively re-introduce some significant Rust Analyzer autocomplete breakages (for things like fn system(value: Res<MyType>) { value.AUTOCOMPLETE_BREAKS }). I'm reasonably sure that the methods used to fix that issue inherently cause the regression (likely the environment variable lookup,the "last edited" lookup in the filesystem, or the mutex lock added to the relatively hot BevyManifest::shared()).

[cart]

I really like the compile-time behavior of the approach above (and I expect it would provide tangible performance improvements, both relative to current main with the regression, and relative to the old approach). But the "cost" is still reasonably high:

1. We lose the module-level docs that come from direct module re-exports
2. Writing macros becomes much harder. If you forget to "cast the spell", bevy-context derives will break
3. Maintaining code becomes harder, as there will be more of it.

[cart]

Another path I tried was using a bevy_crate cargo feature (set on each crate, such as bevy_ecs, in bevy_internal) to do the selection (removing the need for the module redeclaration weirdness), but this does not work because crates like bevy_render that internally use things like derive(Component) will still break in the context of a bevy crate build (because as we know, cargo features are flattened and used to produce a single version of a crate).