nannou-org/nannou
View on GitHubImproving iterative compile times for projects depending on nannou
Open
#387 opened on Aug 18, 2019
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.