TIL, this is missing context, thanks for explaining.

I don't think speed of a full compile (including your dependencies) is the right thing to optimize for -- and incremental compiles don't rebuild dependencies. In a project that depends on serde, for example, most compiles in an ordinary dev cycle are probably not recompiling serde. And sccache reduces the incidence of unnecessary rebuilds far further. Even clean builds tend to get through my dependencies quite quickly.

Except for the most trivial programs, clap should not make a factor of 10 difference, especially for incremental builds.

For serde, I can see it if you use it a lot. There is an experiment to try to cache the macro expansion results to not need to run macro expansion during incremental builds. For full rebuilds, there is an in-work PR to decouple serde's traits from the derive so deserializers can be built in parallel to the rest of your serde code. There is also an RFC for declarative derives. Likely, serde won't be able to use it immediately but we'd like to get it to the point that serde can, getting rid of some big dependencies.

It's worth noting that compiling the same code split up into separate crates compared to in a single crate will usually be faster due to the fact that cargo parallelizes per crate. That doesn't mean that having fewer dependencies won't still potentially help due to reducing the total amount of code that needs to be compiled, or that you couldn't split up the code you're writing yourself into separate crates, but if you're looking to bring in a dependency, the number of transitive dependencies you'd be bringing in as a result isn't necessarily going to be a good heuristic for the amount of extra compile time you'd be adding. In particular, a lot of packages that provide a large amount of functionality are already split up by those developers and then "combined" into a single package that brings them in as dependencies for this exact reason. If they're doing this right, they'll often have these exposed via cargo features that you can disable is they're not needed, and I'd argue that before looking to entirely swap out a direct dependency they're currently using, it's worth checking if the "bloat" they're unhappy with is actually something they can just disable via the feature set in cargo.

Notably, a lot of the "extra" stuff that people have mentioned elsewhere in this thread is stuff that you can potentially turn off when using clap for arg parsing; looking at the documentation[1] to refresh myself, you can opt out of any combination of output color, automatic help text generation, automatic usage documentation, additional context being added to errors, and automatic generation of suggestions when the command is invoked incorrectly, and some of the stuff like being able to derive implementations by default and specific support for Unicode is already off by default.

[1]: https://docs.rs/clap/latest/clap/_features/index.html