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

Make the main bevy crate a dylib #791

Closed
bjorn3 opened this issue Nov 4, 2020 · 11 comments · Fixed by #808
Closed

Make the main bevy crate a dylib #791

bjorn3 opened this issue Nov 4, 2020 · 11 comments · Fixed by #808
Labels
A-Build-System Related to build systems or continuous integration C-Feature A new feature, making something new possible

Comments

@bjorn3
Copy link
Contributor

bjorn3 commented Nov 4, 2020

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

@bjorn3 bjorn3 added the C-Feature A new feature, making something new possible label Nov 4, 2020
@karroffel karroffel added the A-Build-System Related to build systems or continuous integration label Nov 4, 2020
@entropylost
Copy link
Contributor

This should be only enabled during debugging.

@bjorn3
Copy link
Contributor Author

bjorn3 commented Nov 5, 2020

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

@cart
Copy link
Member

cart commented Nov 5, 2020

Ok wow thats absolutely wild:

3d_scene (dylib)

image

3d_scene (default)

image

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

@bjorn3
Copy link
Contributor Author

bjorn3 commented Nov 5, 2020

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
Copy link
Member

cart commented Nov 5, 2020

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
Copy link
Member

cart commented Nov 5, 2020

I'm certainly ecstatic!

@cart
Copy link
Member

cart commented Nov 5, 2020

(Also thanks for your work on rustc_codegen_cranelift)

@cart
Copy link
Member

cart commented Nov 5, 2020

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
Copy link
Contributor Author

bjorn3 commented Nov 5, 2020

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
Copy link
Contributor Author

bjorn3 commented Nov 5, 2020

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

@inodentry
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Build-System Related to build systems or continuous integration C-Feature A new feature, making something new possible
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants