4 ms·
Veloren's compile time is bad, but this is hyperbolic nonsense. To address your points in order: * Compilation is a ton faster on an M1 and with a non-default
by Jweb_Guru 5y ago
Veloren's compile time is bad, but this is hyperbolic nonsense. To address your points in order:
* Compilation is a ton faster on an M1 and with a non-default linker. Compilation from scratch (including all dependencies) took around 10 minutes for me last time I tried; compilation of the main game is much faster (I think in the ~ 1 minute range, which is more than acceptable if you're not doing something sensitive like animation work.). Obviously, not everyone has an M1, but it's hardly a dealbreaker if you've got a machine designed for development.
* The developer in your video is changing a line in veloren-common, a "root" crate that leads to a bunch of other stuff recompiling. The vast majority of changes are in leaf crates, which compile much faster. For animations, in particular (which require quick feedback) we have a separate compilation unit that compiles on the order of seconds and can be configured to be dynamically linked to the main game, so they can get pretty much instant feedback. For as many kinds of assets and data as possible, we also push it out to configuration files with hot reloading, so most people working on models, item and color tweaks, etc. don't have to wait for compilation at all and can just save their files.
* Many games written in C++ also take ages to compile. Rust isn't unique in that regard. Clearly, it hasn't stopped Veloren's development (I can't think of anyone who quit development because of the compile times, though there's a lot of grumbling). In fact, I'd venture to say that Veloren has had some of the most developers and fastest development of any 3D open source game I'm aware of, regardless of language.
* No major developer I'm aware of announced using Rust for games 5 years ago. What are you talking about? If you mean the Chucklefish title, that had nothing to do with compile times. As far as I know, the game companies using Rust right now are mostly using it for tooling.
* The file you linked is the equivalent of yarn.lock, Cargo.toml is the actual dependency file. Dependencies do not need to be recompiled each time you compile Veloren, only the first time. Additionally, most dependencies compile pretty quickly and parallelize well. There are a handful of dependencies (the procedural macro ones in particular) that take a huge percentage of the overall compile time and/or act as bottlenecks, which is tolerated because they are extremely useful.
Veloren could optimize more aggressively for compile time, if the project was so inclined. A lot of that compile time is spent on generated code from macros like serde. Veloren also deliberately tends to use very large crates rather than trying to split everything into very small compilation units (some of them have been split up to improve compile times, but not too much). The project's perspective is that benefits of using those libraries (which greatly simplify development) and having fewer crates (which makes it much easier to avoid exposing internal APIs to get anything done) far outweigh the compile time costs, but not every project takes that approach and there are a lot of games that compile much faster than Veloren. It's really not a fundamental limitation of the language.
- pjmlp 5y ago> Many games written in C++ also take ages to compile. Only if they didn't took the effort to use binary libraries for third party dependencies, or using hot code reloading tools like Live++ or Visual Studio's hot reload for native code. Granted, nothing prevents Rust to have similar options, but they don't seem to be a high priority currently.
- Jweb_Guru 5y agoI mean... if you change the size of a type used by value in a bunch of other places downstream (the equivalent of the change in the video), none of what you're describing is going to help much with compile time, since it's not ABI compatible. For less invasive changes rustc already does a decent (not amazing) job of avoiding recompiling unchanged dependents. As far as initial compile time goes, precompiled binaries would definitely help (on non-overpowered hardware particularly), but initial compile time is not really a development bottleneck since people do not recompile from scratch all that often. I do think people dramatically underestimate how long they would spend waiting for the equivalent C++ libraries to compile when comparing from-scratch compilation times to Rust projects, though, but that's neither here nor there.
- pjmlp 5y agoMostly because compiling from scratch in C++ is seldom a thing outside FOSS environments, all frameworks in gamedev SDKs are binaries already. By the way, Rust incremental compilation is broken again, yes I know of the workarounds.
- Jweb_Guru 5y agoRegardless of what gamedev SDKs with billions of dollars behind them do or do not do, initial compile time is simply not a major bottleneck for developer productivity for Veloren. What is a bottleneck is how long it takes from making a change to seeing it in-game after the initial compile. On that front, C++ and Rust are on pretty similar footing (at least when incremental compilation is working :P) and it mostly comes down to how much the project is prioritizing compile times.