Description
I was investigating the compile time of a crate recently and came across a surprising aspect of the compiler. It looks like the drop glue, or rather the code necessary to drop a type, is inlined unconditionally into the caller crate, even if there are no generics in play.
This program:
pub fn a(_: std::process::Command) {}
generates a whopping 15 thousand lines of LLVM IR. Now Command
certainly is a large type and I think it's fine that its drop glue is that big, but this is a concrete type and every single crate which uses Command
is generating this 15 thousand lines of IR.
At least in debug mode we shouldn't be doing this for concrete types, but rather the destructor of Command
should be compiled into the standard library and then crates which use it should link against this precompiled copy. I would go as far as to argue that this should almost always happen and only when instructed otherwise should the compiler inline destructors across crates (same as for all other methods).
cc @michaelwoerister, do you know if this was a deliberate decision, and is this perhaps something that's relatively easily fixed or something that would be much more intrusive to experiment with?