When following an iterative development methodology compilation time is a concern. In order to safely make a rapid series of small transformations to a program you need to regularly recompile and test the changes you are making. Using an IDE which can do incremental compilation is very helpful, but more complex programs with code and resource generation phases, when using languages without that kind of compilation support, and when verifying that the CI build will work, still require a fast full automated build and test cycle.
In a previous article I discussed a design principal that can be used to try to minimise the amount of time required to do a full compile of all the code in an application.
It is also possible to select design principals which will reduce the amount of recompilation required by any given code change. Conveniently it turns out that same abstract layering approach can be used here too.
We return to the example simple application;
How long is required to compile if a change is made in each component, if each component takes “m” time to compile?
|Component||Compilation Order||Compilation Time|
If we calculate the instability of each module taking into account transitive dependencies. Abusing the definitions slightly we get:
instability = (Ce/(Ca+Ce))
Comparing the instability with the compilation time is interesting. Less stable packages should have lower compilation times, which we see here:
Reducing Recompilation Time
We can restructure our application using the dependency inversion principal. We split each layer into an abstract (interface) layer and a concrete implementation layer.
The application module becomes responsible for selecting the concrete implementation of each layer and configuring the layers of the application. This design pattern is known as Inversion of Control.
Taking into account the ability of a multi-core machine to compile modules in parallel, we get the following minimum compilation times:
|Component Changed||Compilation Order||Compilation Time|
The compilation time for the abstract modules is uniformly 3m, and the compilation time for the concrete modules is uniformly 2m. The application itself is always the last to be compiled so is 1m as before.
How has the design change affected the stability of the modules?
Again we see that the less stable a module is the lower its compilation time:
This example is quite simple, so we see the instability metric of the modules being dominated by the application. It does illustrate however how we can use dependency inversion to help establish an upper bound on the recompilation time for any given change in a concrete module. I will examine a more realistic example in a future article.