This changes ensure that we only compile modules from dependencies
that are used (or transitively used) in the project. This allows to
discard entire compilation steps at a module level, for modules that
we do not use.
The main goal of this change isn't performances. It's about making
dependencies management slightly easier in the time we decide whether
and how we want to manage transitive dependencies in Aiken.
A concrete case here is aiken-lang/stdlib, which will soon depend on
aiken-lang/fuzz. However, we do not want to require every single
project depending on stdlib to also require fuzz. So instead, we want
to seggregate fuzz API from stdlib in separate module, and only
compile those if they appear in the pruned dependency graph.
While the goal isn't performances, here are some benchmarks analyzing
the performances of deps pruning on a simple project depends on a few
modules from stdlib:
Benchmark 1: ./aiken-without-deps-pruning check scratchpad
Time (mean ± σ): 190.3 ms ± 101.1 ms [User: 584.5 ms, System: 14.2 ms]
Range (min … max): 153.0 ms … 477.7 ms 10 runs
Benchmark 2: ./aiken-with-deps-pruning check scratchpad
Time (mean ± σ): 162.3 ms ± 46.3 ms [User: 572.6 ms, System: 14.0 ms]
Range (min … max): 142.8 ms … 293.7 ms 10 runs
As we can see, this change seems to have an overall positive impact on
the compilation time.
TODO: I haven't yet checked the error we get now from trying to compile/type-check a module that contains an unknown module. I reckon it would just fallback to the normal type-checker error, though highlighting something from a dependency which might be slightly confusing.
This changes ensure that we only compile modules from dependencies that are used (or transitively used) in the project. This allows to discard entire compilation steps at a module level, for modules that we do not use.
The main goal of this change isn't performances. It's about making dependencies management slightly easier in the time we decide whether and how we want to manage transitive dependencies in Aiken.
A concrete case here is aiken-lang/stdlib, which will soon depend on aiken-lang/fuzz. However, we do not want to require every single project depending on stdlib to also require fuzz. So instead, we want to seggregate fuzz API from stdlib in separate module, and only compile those if they appear in the pruned dependency graph.
While the goal isn't performances, here are some benchmarks analyzing the performances of deps pruning on a simple project depends on a few modules from stdlib:
As we can see, this change seems to have an overall positive impact on the compilation time.
TODO: I haven't yet checked the error we get now from trying to compile/type-check a module that contains an unknown module. I reckon it would just fallback to the normal type-checker error, though highlighting something from a dependency which might be slightly confusing.