4 ms·
Tokio maintainer here. I've actually been spending a bunch of time recently looking in to how we can reduce Tokio's compile-times. I haven't really been able to
by aliceryhl 5y ago
Tokio maintainer here. I've actually been spending a bunch of time recently looking in to how we can reduce Tokio's compile-times. I haven't really been able to find any big wins yet, but one thing has been pretty clear from the benchmarks: The number of dependencies of Tokio is not the problem. They all compile pretty fast and can all compile in parallel. Tokio itself takes a lot longer than the dependencies.
(Except for tokio-macros which takes a long time because it depends on syn and quote. Consider disabling it if you don't need it.)
- formerly_proven 5y agoSo I've read "syn" and "slow rust compiles" in pretty much every discussion of "slow rust compiles" and finally googled it and... syn is a Rust parser? For use in macros? Because procedural macros operate on tokens and not an AST? Hm. I'm sure there are reasons for how it ended up like this, but it does smell kinda funny.
- jhgg 5y agoIt allows for things like https://docs.rs/typed-html/latest/typed_html/ https://docs.rs/typed-html/latest/typed_html/ to exist.
- dom96 5y agoThis is quite interesting. Is `syn` just an interface to the Rust compiler's Rust parser or is it a completely separate implementation of the parser that works at compile-time? Hopefully it's not the latter but then I wonder where the slowness comes from.
- Cu3PO42 5y agoIf I recall the reason is "rustc's representation of the AST is an implementation detail and unstable, thus macro code may not rely on it (and it will not be exposed)". Hence "syn" came along and provided a stable API and format. "quote" is the inverse function, turning an AST back into tokens.
- snorkel 5y agoFirst of all, Tokio is my favorite async framework, so thank you and the Tokio team! And second, I appreciate that cargo/rustc compiler errors are clear, helpful, and guide me toward cleaner and thread-safe coding where most other languages happily let me create unsafe hidden race bugs all day long with no warning … oh but they compile so much faster! (I don’t care) The slower compile time really doesn’t bother me when I’m getting a more stable end result… but I’m glad the maintainers are working on improving compile time anyway. To me the extra compile time makes sense when rust is showing me many unsafe coding issues that languages seem to ignore even with their strict warnings enabled. … and I don’t get all of the complaining about rust. I’ve written code in a lot of languages and rust has its quirks too, as they all do, but I really like it!
- mamcx 5y agoMacros. This is a major pain. I wish it get more attention (and hopefully: How about a SINGLE way to do macros? Like zig?). Serde is another killer on compiling speed.
- aliceryhl 5y agoWell, one of the advantages of having two ways to do macros is that macro_rules! macros are much much faster than procedural macros.
- mamcx 5y agoYeah, but then why not make it the only one? One reason is that proc-macros can "see" the syntax outside the point of declaration(or enclosed). This means you must do macro_rules! {struct.... } instead of declare the struct first then forward it.