Make the main bevy crate a dylib

[bjorn3]

What problem does this solve or what need does it fill?

Incremental compilation times could be lower.

Describe the solution would you like?

Add crate-type = ["dylib"] to Cargo.toml or add crate-type = ["rlib", "dylib"] to Cargo.toml and -Cprefer-dynamic to the fast compilation profile. On my system it improves the compilation times of the breakout example from 2.1s with the fast compilation profile to 0.9s.

Describe the alternative(s) you've considered?

A lot of different compilation options.

Additional context

I wrote a report of my benchmarking at https://hackmd.io/@bjorn3/BJCQC1eKD

[entropylost]

This should be only enabled during debugging.

[bjorn3]

With crate-type = ["rlib", "dylib"] the dylib will only be used when passing -Cprefer-dynamic.

[cart]

Ok wow thats absolutely wild:

3d_scene (dylib)

3d_scene (default)

@bjorn3 are there any downsides to using dylib over rlib?

[bjorn3]

If using it for the final compilation, it will require you to ship the dylib and libstd.so. It will also result in a bigger combined file size. For development the only disadvantage I am think of is that it may slightly slowdown startup time.

[cart]

Cool cool. It sounds like this should probably be the default for dev workflows (either somehow hard coded into cargo.toml for dev profiles, or just via documentation) . I can't believe a "one line" change makes such a huge difference. Thanks for putting in the work here to gather data / optimize. I'm sure a lot of Bevy developers will be happy you found this 😄

[cart]

I'm certainly ecstatic!

[cart]

(Also thanks for your work on rustc_codegen_cranelift)

[cart]

I can't find a good way to enable this in cargo.toml, but only for dev builds. I think we might be blocked on rust-lang/cargo#7878.

I also can't find a way to pass this in as an argument to cargo run (without environment variables)

So far the best options I know of:

• people just selectively enable this in their cargo.toml during development
• people pass in RUSTFLAGS=-Cprefer-dynamic environment variables as part of their dev workflows (doesnt play nicely with rust-analyzer by default because RA invalidates the build cache. this is probably fix-able by configuring RA to also use -Cprefer-dynamic)
• people use cargo rustc first (with prefer-dynamic), then run the binary directly?

[bjorn3]

If any crate is only available as dylib -Cprefer-dynamic is implicitly set. You could make an empty crate only available as dylib and ask users to do something like #[cfg(debug_assertions)] use bevy_link_as_dylib;.That will only link to that dylib when debug assertions are enabled I think. You could also keep bevy only an rlib if bevy_link_as_dylib has bevy as dependency and contains use bevy;.

[bjorn3]

I added a section for cargo performance and opened rust-lang/cargo#8833 for the results.

[inodentry]

are there any downsides to using dylib over rlib?

Another downside (for release builds) I can think of is that it can limit optimizations if using LTO, reducing the usefulness of LTO.

When everything is linked statically, enabling LTO allows optimizations/inlining to be performed across crates, which can greatly benefit the performance of the app. Having bevy as a separate binary creates a barrier for optimizations between bevy and the app.