We now consider the effects of the evaluator’s function caching in practice. We show the call graphs that result from the evaluation of various packages.
7.6.1 Scratch Build of the Standard Environment
Figure 7.1 shows the call graph that results from evaluating the model for the stan- dard construction environment against an empty cache. In this figure and the next two, the nodes denote function invocations, and an edge from a node f to a node g indicates that f calls g. The edge is solid black if f and g are defined in the same package, and gray otherwise.
The call graph in this example can be divided roughly in half. The left half of the figure shows the evaluation of a stripped down “backstop” standard environ- ment. This environment contains bridges and libraries necessary to build the full standard environment, which is shown in the right half of the figure.
In both cases, building the standard environment entails evaluating bridge mod- els and library models. The library models are divided into three groups: C li- braries, Vesta libraries, and Modula-3 libraries. The full standard environment contains three more bridges than the backstop environment. One of these, the lim bridge, requires more work, since the lim tool exported by the bridge must be built from source.
Note that although this evaluation was performed against a cache that was ini- tially empty, some cache hits still occurred. In particular, cache hits occurred on five of the six bridges in the full environment because identical versions of those bridges had already been evaluated in the backstop environment. Cache hits also occurred on the complete sub-trees of the C and Modula-3 libraries, again because those libraries had been evaluated in the backstop. In contrast, hits did not occur on all of the Vesta libraries because the version of those libraries referenced by the full standard environment model (i.e., version 30) differs from the one referenced by the backstop (version 28). Note that none of the library evaluations resulted in a tool invocation, since in general the actual construction of a library is delayed until a program is built against it.
7.6.2 Scratch Build of the Vesta Umbrella Library
Figure 7.2 shows the call graph that results from building a “hello world” C pro- gram against the complete Vesta umbrella library, assuming that the construction of the standard environment model shown in Figure 7.1 is already cached. The only reason for building such a simple program against the Vesta umbrella is to
cache hit model cache hit new entry new model entry new _run_tool entry
standard environment backstop
lim bridge
Vesta libraries (version 30)
bridges
C libraries
Vesta libraries (version 28)
Modula−3 libraries bridges C libraries Modula−3 libraries lex yacc link
cache hit model cache hit new entry new model entry new _run_tool entry
compile hello.c
link hello program
build standard construction environment
GC library prebuilt libraries Basics library RPC library archive config n
library compile config library
Log library Fingerprint library Repository library Function Cache library
compile RunTool library archive RunTool library
illustrate the construction of the umbrella, which constitutes the bulk of this figure. The actual construction of the hello world program itself consists only of the two rightmost tool invocations.
Although the function cache is relatively empty in this example, the importance of good caching is evident. The cache hit on the standard construction environment in the upper left of the figure is critically important, as it saves the evaluator from having to evaluate the entire call graph of Figure 7.1!
Perhaps the main thing to notice about this call graph is its sheer size. Building the Vesta umbrella library from scratch requires 86 tool invocations. Except for the fingerprint library, each sub-library is constructed by compiling the library’s sources one at a time, and then collecting the resulting objects together into a li- brary archive.
The construction of the fingerprint library requires a bit more work, since a program for generating a header file of computed fingerprint constants must first be built and run. This example shows how the intermediate results of a build (namely, the program for generating the header file) can be invoked later in the build. It also illustrates that Vesta’s distinction between source and derived files is not the same as the C compiler’s distinction between source and object files; here, a C source file is mechanically generated, not stored directly in the repository, so it is a derived from Vesta’s point of view.
7.6.3 Scratch and Incremental Builds of the Evaluator
Figure 7.3(a) shows the call graph that results from building the Vesta evaluator package from scratch, assuming that the standard environment and Vesta umbrella library are cached. In addition to the Vesta evaluator executable, building the pack- age also causes a helper program and some derived documentation files to be con- structed.
This figure is an even better example of the importance of effective caching. In this case, there is a hit not only on the evaluation of the standard construction envi- ronment, but also on the entire Vesta umbrella library shown in Figure 7.2. Hence, the 86 tool invocations shown in that previous figure are all avoided by virtue of a single cache hit. The construction of the evaluator itself is straightforward: its 18 sources are compiled into objects, and those objects are then linked together against the Vesta umbrella library. The construction of the helper program and documentation files is also straightforward.
Figure 7.3(b) shows the call graph that results from an incremental build of the Vesta evaluator. This example illustrates the typical case that occurs during the inner edit-build-test loop of the development cycle. This figure was produced by starting with the cache that resulted from the evaluation of Figure 7.3(a), modify-
hit building Vesta umbrella library
compile Vesta evaluator sources link Vesta evaluator hit building standard
construction environment build docs build helper program (a) cache hit model cache hit new entry new model entry new _run_tool entry hit building standard
construction environment
hit building Vesta umbrella library hit compiling first 9 Vesta evaluator sources
recompile modified source file hit building evaluator docs hit building helper programs re−link Vesta evaluator (b)
Figure 7.3:The call graphs that result from building the Vesta evaluator package from scratch (a) and again after one of the evaluator’s source files has been modified (b). In both cases, hits occur on the standard construction environment and the Vesta umbrella libraries.
ing one of the evaluator’s source files, and rebuilding. In this case, there are many cache hits and only two tool invocations (one to recompile the modified source and one to relink the evaluator executable). Because the helper program and documen- tation sources were not changed, high-level cache hits occur on those parts of the evaluation.
This example also illustrates an interesting feature of the C and C++ bridges. In particular, notice that the compilation of 10 or more sources in a library or application produces a balanced subtree in the call graph so that no more than 9 files are compiled together directly under a single node. This “weeping willow” effect is especially evident in the construction of the GC library in Figure 7.2. When the evaluator was built from scratch, the compilation of its 18 sources was automatically divided by the bridge into two groups of 9. As a result, the work required to recompile the files in the first group can be avoided by a single cache hit. In the general incremental case, this divide-and-conquer technique results in a number of cache lookups proportional to the logarithm of the number of sources in the library or application, rather than the linear number that would result if the naive flat organization had been used.