Some non-trivial(above 100k loc) Rust projects I'm working on or have worked on before all have some kind of compile-time/bloat issues. The compile time is almost tolerable, but besides time, there is one common problem: they all generate very large debug files, for example, a pdb file larger than 1GB.
I suspect the real issue causing the debug info bloating is that there are many very long type names. In my project, or I assume many Rust projects, use very complex and nested types to model the problem and express the zero-cost abstraction is a recommended pattern(for example iterators futures). However, this approach tends to create very long type names when compiling.
I use a pdb parser to read the 1GB pbd files I mentioned above and do some analysis. It turns out the type name takes 56% of that pdb file in byte size. There is not a single very long name, but hundreds of thousands of very long type names. In that project, I have already do a lot of trait boxing to avoid long type name.
Very long type names may cause the linker to fail, increase compile time, and bloat the compiler debug output substantially. Long type names is not useful at all when debugging. In my opinion, this is an important and practical issue for Rust, because it directly hinders the most common Rust coding/architecture style.
So I suggest adding some forms of compiler configuration: For type names exceeding the given threshold, only generate names for the outer part of the type, using an opaque ID or hash for the internal part to avoid creating very long type names in any compiling stage.
If I enable more optimization in debug build, the pdb size and executable size will reduce a lot start from o1. but the all_name_size/pdb_size ratio stays same.
If the name size larger than 1000 byte considered large name(5-10 lines in typical console window). Then for that 928mb pdb, all large name takes 370mb(40%), all name is 540mb(59%).
I also print the name size histogram of the large names: