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

Improving iterative compile times for projects depending on nannou #387

Open
3 tasks
mitchmindtree opened this issue Aug 18, 2019 · 4 comments
Open
3 tasks
Labels
good first issue user experience Anything that affects how users interact with the framework

Comments

@mitchmindtree
Copy link
Member

mitchmindtree commented Aug 18, 2019

Slightly related to #178 but more focused on iterative compile times than fresh ones.

Currently it's easy to reach fairly significant compile times even for small projects (e.g. 10+ secs). I think there's likely a lot we could do to improve this situation with the design of nannou itself.

Here are some steps I think we could take:

  • First, setup a reliable iterative compilation time bench-marking process. This should have some way of measuring iterative re-compile times for many different size projects including both examples and more significant downstream projects like spatial_audio_server. Just getting a setup working for examples would be a good start. I believe rustc provides a way to get a breakdown of exactly where the compiler is spending most of its time, though I don't remember how to do this off the top of my head.
  • Survey the surface-level of nannou's API. Attempt to remove generic types in favour of dynamic dispatch where possible. This should be more than doable in many of the top-level APIs without any significant performance penalty.
  • Encourage code generation during library compile-time where possible. E.g. perhaps providing type and function wrappers around generic types and functions with their type parameters filled using the default type will assist the compiler to pre-generate a lot of code for the common use case?

Any other ideas are welcome!

I've labelled this as good-first-issue as this might be a nice way to become familiar with a lot of nannou's internals and rust benchmarking tools.

@mitchmindtree mitchmindtree added good first issue user experience Anything that affects how users interact with the framework labels Aug 18, 2019
@mitchmindtree
Copy link
Member Author

Some interesting discussion on this issue popping up here.

@michal-z
Copy link

michal-z commented Mar 6, 2020

On Windows using LLVM lld-link.exe instead of MS linker improves build times. Please see here: rust-gamedev/wg#50

@mystal
Copy link

mystal commented Apr 30, 2020

On another project I'm working on, the biggest compile time improvements were:

  1. Use lld to link on supported platforms.
  2. For debug builds, set debug = false to remove all debug info from the binaries. I rarely use a debugger to debug Rust, and having this turned on increases the build time quite a bit! So I have it off by default and toggle it on if I ever need to attach a debugger.
  3. Deduplicate dependencies when possible--i.e. only have one version of each dependency, especially syn/quote. This is less of a problem for incremental compilation, but I think it helps.

@kazimuth
Copy link
Contributor

kazimuth commented Oct 9, 2020

See also the "enable fast compiles" section of the Bevy setup guide: https://bevyengine.org/learn/book/getting-started/setup/

I've found that switching to those settings + a nightly compiler greatly speeds things up. It takes my mid-sized sketches (2-400 LOC) to 1second incremental recompiles. Adding debug=false to debug builds speeds things up even more, and you'll still get stack traces on panic, debuggers just won't work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue user experience Anything that affects how users interact with the framework
Projects
None yet
Development

No branches or pull requests

4 participants