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

register_component / register_resource calls cause noticeable growth in compile time #643

Open
philpax opened this issue Sep 13, 2024 · 0 comments

Comments

@philpax
Copy link
Contributor

philpax commented Sep 13, 2024

I was investigating why our protocol crate was so slow to build, and narrowed it down to register_component / register_resource. To reproduce this, I created compiletime_test as an example in examples:

examples/compiletime_test/Cargo.toml:

[package]
name = "compiletime_test"
version = "0.1.0"
edition = "2021"

[dependencies]
lightyear = { path = "../../lightyear", features = ["webtransport"] }
bevy = { version = "0.14", default-features = false, features = [
    "multi_threaded",
    "bevy_state",
    "serialize",
] }
serde = { version = "1.0", features = ["derive"] }

examples/compiletime_test/src/main.rs:

use bevy::prelude::*;
use lightyear::prelude::*;

macro_rules! register_components {
    ($($component:ident)*) => {
        fn register_components(app: &mut App) {
            $(
                #[derive(Component, Serialize, Deserialize, PartialEq, Clone)]
                struct $component;

                app.register_component::<$component>(ChannelDirection::Bidirectional);
            )*

            $(
                app.world_mut().spawn(($component,));
            )*
        }
    };
}

register_components!(C1);
// register_components!(C1 C2 C3 C4 C5);
// register_components!(C1 C2 C3 C4 C5 C6 C7 C8 C9 C10);
// register_components!(C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 C15 C16 C17 C18 C19 C20 C21 C22 C23 C24 C25 C26 C27 C28 C29 C30 C31 C32 C33 C34 C35 C36 C37 C38 C39 C40 C41 C42 C43 C44 C45 C46 C47 C48 C49 C50);
// register_components!(C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 C15 C16 C17 C18 C19 C20 C21 C22 C23 C24 C25 C26 C27 C28 C29 C30 C31 C32 C33 C34 C35 C36 C37 C38 C39 C40 C41 C42 C43 C44 C45 C46 C47 C48 C49 C50 C51 C52 C53 C54 C55 C56 C57 C58 C59 C60 C61 C62 C63 C64 C65 C66 C67 C68 C69 C70 C71 C72 C73 C74 C75 C76 C77 C78 C79 C80 C81 C82 C83 C84 C85 C86 C87 C88 C89 C90 C91 C92 C93 C94 C95 C96 C97 C98 C99 C100);
// 1000 example elided

fn main() {
    let mut app = App::new();
    register_components(&mut app);
    app.run();
}

and then rebuilt it with the following command to ensure the dependencies remained built, but the binary itself was being built from scratch:

rm -rf target/debug/.fingerprint/compiletime_test* && rm -rf target/debug/incremental/compiletime_test* && rm -rf target/debug/compiletime_test* && cargo build -p compiletime_test

Here's the data I collected:

n without register_component with register_component
1 3.00 9.13
5 3.00 10.57
10 3.13 12.09
50 3.28 24.09
100 3.88 41.87
1000 14.28 391.00

Plotted, just for the fun of it:
image

This is also true of register_resource. I tested with

        fn register_components(app: &mut App) {
            $(
                #[derive(Resource, Serialize, Deserialize, PartialEq, Clone)]
                struct $component;

                app.register_resource::<$component>(ChannelDirection::Bidirectional);
            )*

            $(
                app.world_mut().insert_resource($component);
            )*
        }

as the body of the macro, and found the following (didn't test all of the cases):

n without register_resource with register_resource
5 3.12 11.99
50 3.22 25.11

My suspicion is that this is due to monomorphisation generating junk code, but I haven't been able to confirm that yet.

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