Soft question: Significantly improve Rust compile time via minimizing Generics?

[scottmcm]

@kpreid

In this case, you can improve compile time and code size by making the non-generic part a separate, non-generic function:

You'll see this particularly often in the standard library for things using paths. For example,

rust-lang/rust/blob/ae612bedcbfc7098d1711eb35bc7ca994eb17a4c/library/std/src/fs.rs#L295-L304

You can call that with a &str or a String or a PathBuf, but it would be silly to instantiate all the file-reading parts again for each of those.

So instead the standard library has a concrete version that only takes &Path, and the monomorphized part is just the trivial inlinable wrapper that turns the &str to a &Path or similar.

@anon80458984

so now we have the problem that Foo itself is generating lots of code due to the procedural macros, but then we do it once per Tag we instantiate.

Note that generics are often a big win if what you care about is how much the macro has to generate. Because proc-macro parsing and emitting for one generic struct is much cheaper than making the proc-macro look at all the concrete types.

When it comes to codegen stuff, 3 different concrete types or 3 instantiations of one generic type behave about the same, other than in where it happens in your crate graph. There's nothing about things like debuginfo generation that cares whether it's an orginally-concrete type or an instantiation of a generic.