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

Document Compile Time Optimization By Disabling Debug Symbols #126

Closed
zicklag opened this issue Aug 11, 2020 · 4 comments
Closed

Document Compile Time Optimization By Disabling Debug Symbols #126

zicklag opened this issue Aug 11, 2020 · 4 comments
Labels
A-Build-System Related to build systems or continuous integration C-Docs An addition or correction to our documentation

Comments

@zicklag
Copy link
Member

zicklag commented Aug 11, 2020

I noticed that when re-compiling the examples, I would get a little bit faster re-compile times when using release mode presumably because debugging symbols actually can make debug compile times slower than the release build compile times ( mentioned here rust-gamedev/wg#50 (comment) ). Seems like this is worth mentioning in the fast compile section of the documentation.

If you don't need debug symbols it may actually be faster to compile and result in a faster game to use release mode. Also you can add the following to your .cargo/config to disable debug symbols when making debug builds, but when recompiling the examples that only makes it take the same amount of time as a release build:

[profile.dev]
debug = false
@tbillington
Copy link
Contributor

Would this also include things like overriding the opt level for dependencies in dev mode? Perhaps more of a execution speed thing?

# Set the default for dependencies.
[profile.dev.package."*"]
opt-level = 2

https://doc.rust-lang.org/cargo/reference/profiles.html#overrides

@cart
Copy link
Member

cart commented Aug 12, 2020

The examples do iteratively compile faster in release mode for the reason you mentioned (and also probably because optimization results in smaller binaries). I think this win will get dwarfed as the "complexity" of a game goes up, but I havent tested that personally.

However iterative engine builds (ex changing something in bevy_ecs) do get worse in release mode. So its sort of a question of "do we optimize the defaults for engine developers or first time bevy users testing out the examples".

The selfish pragmatist in me wants to optimize for "first time bevy users", but in this case the real consumer of this repo is bevy developers, so the developer in me wants to optimize for them.

@zicklag
Copy link
Member Author

zicklag commented Aug 12, 2020

I think it makes sense to default to the user-friendly, first-time advantage and to document the developer advantage strategy, because somebody who wants to contribute to the engine will already have to do a little bit of digging to do useful stuff, so just a note on the "Quick Compile Setup" section will probably be sufficient to note how to optimize for engine dev.

For me, as both a non-beginner game developer and a potential engine developer ( so more on the dev side ), I would just want a paragraph explaining the different compile-time, debug symbol, optimization level options and their general effect so that I can decide how I want to configure my project.

@karroffel karroffel added A-Build-System Related to build systems or continuous integration C-Docs An addition or correction to our documentation labels Aug 12, 2020
@alice-i-cecile
Copy link
Member

This is pretty well documented in the Bevy book now.

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-Docs An addition or correction to our documentation
Projects
None yet
Development

No branches or pull requests

5 participants