No AI is used in my work; or research; or writing; or anything else really.

(=｀ェ´=) Go to your Rust codebase and pick a dependency. How much do you use that dependency? How many functions do you use from bitflags? From chrono? From hashbrown? How many items does your dependency pull from other dependencies? And how many end up being linked in the final binary or re-compiled during compilation?

Better insights without target bloat

（=´∇｀=） Incremental Systems Rethought started as a project goal on July 7th 2026, that same day I started making progress towards a few optimizations that all relied on the same initial infrastructure. That initial infrastructure is just an experiment that reads incremental information on the initial stages of compilation (so, just after registering a dependency into the workspace).

This gives us a lot of already-existing information about what is inside that new dependency. In that way, we can preemptively know what every dependency thinks of its dependencies, and of itself.

The reason why this wasn’t done already is because it has its downsides. The compiler deadlocks (i.e. enters a state where two mutexes are waiting on each other!) extremely easy. The TyCtxt, the key structure inside the compiler is not fully formed (or even fully valid), so heavily intertwined things like span information are not accessible.

So, decoding anything that contains a Span at this stage (which is most of the compiler), will deadlock, ICE, or a mystery third option! Also, a subset of queries (a special type of function that caches its own result) also panics because they’re not defined yet (yes, a part of the compiler is self-programmed at runtime)

Still at this fragile state, we can get some interesting information! Such as having a third-party dependency graph of the compiler based purely on metadata!

Why is this important

The fact that we can get a dependency graph from metadata in the compiler does not seem particularly relevant for anything, but it means something far greater. We can know with more or less exact certainty, the relevance of a dependency in a proyect.

Dependencies consume compile times, disk space, and might not be all that optimized for your usecase. So while bigger dependencies like runtimes or standard-format parsers (like JSON) are not really feasable to re-make and maintain, you should always strive to reduce unnecessary dependencies on your code.

With that said, let’s analyze the metadata dependency graph of… Bevy!

(See the full graph here colorized. The brighter red a line is, the more functions come from that function)

…

Okay, turns out that core is used a lot in hashbrown. This happens because hashbrown is a pretty big crate (15.5K LoC), with 0 required dependencies, not even the standard library! And many items in core depend on other items in core.

As you can see, core is also an extremely used dependency for the other crate (except for a build script, internally identified by build_script_build, which depends heavily on object, a dependency pulled in via std itself)

Going to the other extreme, we get that a lot of dependencies rely on 1 instance of hashbrown. I’m not sure if this is just a left-over from the compiler declaring hashbrown as existing.

3 seconds shaved on compilation

But really what I’d qualify as more interesting are the values in the middle. Concluding that core is used a lot and that hashbrown is not used at all is not relevant nor interesting. What about crates that are used 1-5 times? Are those crates really necessary?

After 5 minutes of analysis I found an unnecessary itertools dependency on the compiler module rustc_ast_pretty. Removing that dependency (and replacing the 2 trivial functions that were used) improved compile times for that module by 3 seconds. 3 SECONDS!! (13.57s -> 10.58s)

You’re reading that right. A static analysis tool found an irrelevant dependency that other tools like cargo-shear coul not find!

Conclusion

Rethinking the incremental compiler is a tough challenge that will require hundreds of hours. I started thinking about it more than a year ago, and it’s the absolute peak in my optimization work. I love sharing this kind of things so that everyone can be a little happier today, knowing that Incremental Systems Rethought is finally coming after more than a year of planning.

Thank you for accompanying me through this trip, peace and have a great day.