Excessive rustc memory usage and compile time

[imre-kis-arm]

Summary

When a crate defines a large number of bitflags! types, rustc memory consumption and compilation time grow approximately linearly with the number of generated types. The growth is large enough to make real-world scenarios hit practical memory limits.

The issue appears to be primarily related to the number of generated trait implementations, as the bitflags! macro generates implementations for several traits (such as Add, Sub, BitOr, etc.) for the type.

Reproducer

Cargo.toml

[package]
name = "rustc-mem-measure"
version = "0.1.0"
edition = "2024"

[dependencies]
bitflags = "2.13.0"

src/lib.rs

use bitflags::bitflags;

macro_rules! create_bitflags_instance {
    ($name:ident) => {
        bitflags! {
            pub struct $name: u64 {
                const BIT0  = 1 << 0;
                const BIT1  = 1 << 1;
                const BIT2  = 1 << 2;
                const BIT3  = 1 << 3;
                const BIT4  = 1 << 4;
                const BIT5  = 1 << 5;
                const BIT6  = 1 << 6;
                const BIT7  = 1 << 7;
            }
        }
    };
}

create_bitflags_instance!(Type0);
create_bitflags_instance!(Type1);
create_bitflags_instance!(Type2);
create_bitflags_instance!(Type3);
create_bitflags_instance!(Type4);
create_bitflags_instance!(Type5);
create_bitflags_instance!(Type6);
create_bitflags_instance!(Type7);
create_bitflags_instance!(Type8);
create_bitflags_instance!(Type9);
// ...

Note that the create_bitflags_instance! macro is only used to simplify the example. Replacing it with manually written type definitions has only a minimal effect on resource consumption.

Observed scaling

Type count	Memory usage (MB)	Time (s)
1	33.3	0.2
10	63.2	1.0
100	393.5	9.7
1000	4391.5	104.6

Memory usage and compile time both scale approximately linearly with the number of generated bitflags! types.

Toolchain

The measurements were collected using a custom debug-built toolchain (dc375db7d8df0aa450e622c529147c95eee756f5). However, similar behavior is observed across multiple toolchain versions, including Rust 1.80 through the latest stable available at the time of writing (1.96.0 (30a34c682 2026-05-25)).

Profiling information

Using the debug-built toolchain, the largest memory consumers observed in the rustc process were:

MB	% of useful heap	Consumer
797.7	18.16%	2,714 places below Massif threshold
502.4	11.44%	rustc_resolve::Module::for_each_child / Resolver::finalize_imports
438.5	9.99%	rustc_arena::DroplessArena::grow
386.6	8.80%	rustc_middle::dep_graph::CurrentDepGraph::record_edge
367.7	8.37%	indexmap::Core<rustc_span::SpanData, ()>::insert_full

Real-world impact

This issue was discovered while developing the Arm system register crate: arm-sysregs The crate generates types and accessors for Armv8-A system registers. Currently only about 25% of the registers are covered, yet builds are already approaching CI memory limits (~3 GB).

The current scaling is therefore problematic because:

• Memory requirements continue to grow as more registers are added. When the crate is complete, the extrapolated memory usage of rustc will be ~12GB.
• Downstream projects compiling the crate inherit the cost.
• Parallel builds amplify the problem because multiple rustc processes compete for memory simultaneously.

Questions

1. Are there known coding patterns in bitflags!-generated code that contribute disproportionately to memory usage and should be avoided?
2. Are there ongoing or planned efforts to reduce rustc memory consumption for workloads involving large numbers of types and trait implementations?
3. The profiling results suggest significant memory usage in dependency graph tracking and related compiler infrastructure. Would it be feasible to introduce more cache-like behavior where less frequently used entries can be discarded and recomputed when necessary, rather than retaining all information for the duration of compilation?
4. Are there alternative approaches, compiler flags, or code-generation patterns that could mitigate this issue?

Expected outcome

• rustc memory usage for this pattern could be reduced substantially, or
• Guidance could be provided on which language/library patterns are responsible for the scaling and how generated code can be structured to avoid them.

Any suggestions for investigation or mitigation would be greatly appreciated.

[saethlin]

I suggest breaking all these registers into separate crates, possibly along arbitrary boundaries, then re-exporting them through a facade crate. If possible, I also suggest removing trait impls or helper functions from the bitflags macro expansion.

It is infeasible for a compiler to have better than O(n) scaling, so it's quite odd that you pointed that out.

There are probably other things we could do to improve this scenario, but to be honest this entire issue is just "rustc is inefficient" and while I agree with you, I think our inefficiency is death by a thousand cuts.

I think there are probably some optimizations we could implement that would improve resource use for this build but it is unlikely to be percentages large enough to be exciting and merged quickly enough to unblock your work. For example, every 1 << 0 is lowered as an inline const and it is just a bit too complicated for my trivial consts optimization to apply: #148040. It could be extended to consider those trivial. But that's probably a drop in the bucket compared to the dozens of const fn bodies that get compiled per register.

[theemathas]

I'd recommend using feature flags so that users of your crate would only need to compile the stuff that they actually need.

[saethlin]

Maybe it's possible to cut down on the amount of items here by using abstraction instead of code generation? IMO the code generation is the problem here, it's just a monstrous amount of copy-paste.

Can you do something like

trait Register: Sealed + Copy {
    fn bits(self) -> u64;

    // Then provide implementations of everything else you need
}

struct Type0(u64);
impl Register for Type0 {
    fn bits(self) -> u64 {
        self.0
    }
}

I don't know if literally this will work for you, but something like this where you can delegate to one implementation should reduce the amount of work the compiler has to do. (I tried to slap this example together and immediately ran into an orphan rules problem trying to do a Sub impl, so exactly my suggestion might not work, the idea of centralizing the code is my point)