Ideas on how to improve compile-time #987
Description
Summary 💡
De-monomorphisation
Function like gix::clone::PrepareFetch::new can be trivally de-monomorphised by extracting an inner function.
@Byron It's possible we can do this without sacrificing code readability by creating our own variant of momo.
For gix::clone::PrepareFetch::fetch_then_checkout it would be harder since Progress is not an dyn-safe trait.
I would like to add another provided method to Progress:
/// An opaque type so that `gix` can internally change its implementation details,
/// e.g. use an `Arc` instead of `Box`, or even inlining the progress.
pub struct DynProgress;
impl DynProgress {
pub fn new<P: Progress>(p: P) -> Self;
}
impl Progress for DynProgress {
type SubProgress = Self;
// ...
}
trait Progress {
// ...
// Provided method
fn into_dyn_progressive(self) -> DynProgress;
}Features
For starters, I think we can put gix_negotiate, gix_ignore and gix_utils behind new feature flags.
Then we can put ability to fetch and update new repository into its own features since many crates might just want to discover local repository, e.g. vergen.
Motivation 🔦
As shown in cargo-bins/cargo-binstall#1304 (comment) , compilation of gix (not its dependencies) on GHA MacOS runner took more than 60s, which is a bit too long.
simple-git, which only uses a few gix interface, also takes 34s just to compile.
I believe this is caused by two factors:
- too much monomorphization
- too many unused code and dependencies pulled in
Progress
- Use
dynwhere possible, includingdynbased progress traits #1008 -
gixfeature toggles #1010 -
gix-errorcrate as replacement forthiserror