7 ms·

First things first: congratulations on your success! You seem to have single-handedly lit a fire under the Rust gamedev ecosystem :) When I heard about Bevy la

First things first: congratulations on your success! You seem to have single-handedly lit a fire under the Rust gamedev ecosystem :) When I heard about Bevy last year, I was skeptical that game developers could achieve good iteration times by compiling Rust code in debug mode. It clearly works well for small programs, but I was concerned that it might not scale; in particular, that large dependencies might slow down linking, that CPU-intensive games would be likely to run at non-interactive speeds in debug mode, and that just a few seconds of compile time might be enough to break developers' flow. When people are working on large game projects in Bevy, have they encountered these problems in practice? If not, how have the problems been avoided? (Full disclosure: I developed GameLisp, a scripting language for Rust games, partly motivated by compiled languages' poor iteration times.)

dralley 5y ago
To this point, do you actively measure code size and compile times for regressions? And if so, how?
- _cart 5y ago
  Sadly we don't yet have top tier compile time tests like rust does (https://perf.rust-lang.org/ https://perf.rust-lang.org/). We have a history of CI durations over time, but this is a rough metric given that we both optimize our CI constantly and testing on github vms isn't the cleanest environment. I run `cloc` on our repo every so often, but this also isn't a "metric" we drive down. We can (and should) build up testing infrastructure for all of this.
_cart 5y ago
Iterative compile times are definitely a constant consideration for us. Some various thoughts on this topic: * For faster iteration on game logic, you can compile app logic in debug mode and the engine in release mode. App logic is rarely the bottleneck when compared to internal systems like rendering. * Dynamic linking has been a huuuuge win for us. Dynamically linking often gives sub-second iteration times for our examples. Of course, as your app logic/crates get bigger it is more important for you to manage compile time complexity on your end (and we have seen bigger projects notice this trend). Developers can control this by modularizing their code (and dynamically linking these modules when necessary). I'd like to build templates and tooling that encourages people to follow these patterns. * We have an optional "fast compiles" configuration (check out our quick start guide), which gives additional significant compile time boosts (ex: faster linkers, generic sharing, etc). * Dynamic linking is just one piece of the puzzle. We need to constantly drive down code size and complexity (by limiting things like generic usage) and dependencies to ensure that userspace compiles as quickly as possible, with or without dynamic linking. Macroquad is the pinnacle of this minimization in the rust ecosystem (imo), but they make way more compromises in terms of "rust ecosystem usage" and api design than I am willing to. My goal is to strike an ideal balance between these (often conflicting) goals.

dralley 5y ago

To this point, do you actively measure code size and compile times for regressions? And if so, how?

_cart 5y ago
Sadly we don't yet have top tier compile time tests like rust does (https://perf.rust-lang.org/ https://perf.rust-lang.org/). We have a history of CI durations over time, but this is a rough metric given that we both optimize our CI constantly and testing on github vms isn't the cleanest environment. I run `cloc` on our repo every so often, but this also isn't a "metric" we drive down. We can (and should) build up testing infrastructure for all of this.

_cart 5y ago

Iterative compile times are definitely a constant consideration for us. Some various thoughts on this topic: * For faster iteration on game logic, you can compile app logic in debug mode and the engine in release mode. App logic is rarely the bottleneck when compared to internal systems like rendering. * Dynamic linking has been a huuuuge win for us. Dynamically linking often gives sub-second iteration times for our examples. Of course, as your app logic/crates get bigger it is more important for you to manage compile time complexity on your end (and we have seen bigger projects notice this trend). Developers can control this by modularizing their code (and dynamically linking these modules when necessary). I'd like to build templates and tooling that encourages people to follow these patterns. * We have an optional "fast compiles" configuration (check out our quick start guide), which gives additional significant compile time boosts (ex: faster linkers, generic sharing, etc). * Dynamic linking is just one piece of the puzzle. We need to constantly drive down code size and complexity (by limiting things like generic usage) and dependencies to ensure that userspace compiles as quickly as possible, with or without dynamic linking. Macroquad is the pinnacle of this minimization in the rust ecosystem (imo), but they make way more compromises in terms of "rust ecosystem usage" and api design than I am willing to. My goal is to strike an ideal balance between these (often conflicting) goals.