nannou-org/nannou

Improving iterative compile times for projects depending on nannou

Open

#387 opened on Aug 18, 2019

View on GitHub
 (4 comments) (0 reactions) (0 assignees)Rust (4,662 stars) (254 forks)batch import
good first issueuser experience

Description

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.

Contributor guide