4 ms·

Rust macros are not the fault for its slowness. expansion is one of the fastest compilation phases. Time is rather spent in other steps like type checking, llvm

by est31 4y ago

Rust macros are not the fault for its slowness. expansion is one of the fastest compilation phases. Time is rather spent in other steps like type checking, llvm optimizations and such. The issue is more Rust's generics as they cause a lot of code to be passed to llvm (among other issues for Rust's slowness).

Arnavion 4y ago
Macro expansion is slow, but only noticeably in the specific situation of a) third-party proc macros, b) a debug build, and c) a few thousand invocations of said proc macros. This is because building in debug mode also compiles proc macros in debug mode, so while the macro itself compiles quickly (because it's an unoptimized build), it ends up running slowly (because it's an unoptimized build). I know this from observing a ~90s difference between debug and release builds, of a large (mostly auto-generated) crate that had a couple of thousand `#[derive(serde::*)]`s. [1] This doesn't affect most users, because first-party macros like `#[derive(Debug)]` etc are not slow because they're part of rustc and are thus optimized regardless of the profile, and even with third-party macros it is unlikely that they have thousands of invocations. Even if it is a problem, users can opt in to compiling just the proc macros in release mode. [2] [1]: https://github.com/Arnavion/k8s-openapi/issues/4 https://github.com/Arnavion/k8s-openapi/issues/4 [2]: https://github.com/rust-lang/cargo/issues/5622 https://github.com/rust-lang/cargo/issues/5622*
- est31 4y ago
  > Macro expansion is slow, but only noticeably in the specific situation of a) third-party proc macros, b) a debug build, and c) a few thousand invocations of said proc macros. Oh that's interesting. But note that it's an issue caused by (from the perspective of the language) user code being slow, and also only if you compile in debug mode. You probably don't want to unconditionally compile proc macros in release mode, as most times they probably don't get invoked thousands of times. Ideally you would probably a) invoke macros in a parallel fashion, with multiple expansion threads, and b) maybe have rustc signal to cargo somehow that there are tons of invocations of a specific macro and that it might make more sense to recompile the proc macro with optimizations turned on.

by est31 4y ago

Arnavion 4y ago

Macro expansion is slow, but only noticeably in the specific situation of a) third-party proc macros, b) a debug build, and c) a few thousand invocations of said proc macros. This is because building in debug mode also compiles proc macros in debug mode, so while the macro itself compiles quickly (because it's an unoptimized build), it ends up running slowly (because it's an unoptimized build). I know this from observing a ~90s difference between debug and release builds, of a large (mostly auto-generated) crate that had a couple of thousand `#[derive(serde::*)]`s. [1] This doesn't affect most users, because first-party macros like `#[derive(Debug)]` etc are not slow because they're part of rustc and are thus optimized regardless of the profile, and even with third-party macros it is unlikely that they have thousands of invocations. Even if it is a problem, users can opt in to compiling just the proc macros in release mode. [2] [1]: https://github.com/Arnavion/k8s-openapi/issues/4 https://github.com/Arnavion/k8s-openapi/issues/4 [2]: https://github.com/rust-lang/cargo/issues/5622 https://github.com/rust-lang/cargo/issues/5622*

est31 4y ago
> Macro expansion is slow, but only noticeably in the specific situation of a) third-party proc macros, b) a debug build, and c) a few thousand invocations of said proc macros. Oh that's interesting. But note that it's an issue caused by (from the perspective of the language) user code being slow, and also only if you compile in debug mode. You probably don't want to unconditionally compile proc macros in release mode, as most times they probably don't get invoked thousands of times. Ideally you would probably a) invoke macros in a parallel fashion, with multiple expansion threads, and b) maybe have rustc signal to cargo somehow that there are tons of invocations of a specific macro and that it might make more sense to recompile the proc macro with optimizations turned on.