Did you do it from a clean build? In that case, it's actually a slightly misleading metric, since rust needs to actually compile macros in order to typecheck code that uses them. (And therefore must also compile all the code that the macro depends on.) My bad for suggesting it, haha. Incremental cargo check is often a better way of seeing how long typechecking takes, since usually you haven't modified any macros that will need to be recompiled. On my project at work, incremental cargo check takes `1.71s`.
replySide note: There's an effort to cache proc macro invocations so that they get executed only once if the item they annotate hasn't changed: https://github.com/rust-lang/rust/pull/129102
replyThere are multiple caveats on providing this to users (we can't assume that macro invocations are idempotent, so the new behavior would have to be opt in, and this only benefits incremental compilation), but it's in our radar.
That is something I never have to care on my C++ projects, because I always make use of binary libraries, unless I am forced to compile from source.
replyUnfortunately that doesn't seem to ever be a scenario cargo will support out of the box.
The actual reason that you don't have to care about this on your C++ project is because C++ doesn't let you define macros in C++, you can only define them in the preprocessor language. Therefore no compilation is needed to execute them.
replyI never write macros in C++, other than header guards, for years now.
replyI belong to the school of thought that C style macros in C++ should be nuked.
Exception being source code I don't own.
A ton of that is actually still doing codegen (for the proc macros for example).
reply