Program changes and the cost of selective recompilation
James H. Morris, Ellen Borison · 1989
When module boundaries are dissolved, a program can be seen simply as a collection of named objects (procedures, types, variables, etc.) that reference one another. Program designers impose order on such collections by grouping somehow-related names into modules. Informed by over twenty years of software engineering wisdom, we trust that modularization makes programs easier to control, maintain, and understand. However, not all of the effects of modularity are beneficial. This research suggests that most of the recompilations performed after a change to an interface are redundant and that this redundancy is a direct consequence of how we modularize software systems. This conclusion is based on the careful analysis of a small number of C and Ada programs. This analysis in turn is based on a model of software manufacture that specifically addresses the question of how much work has to be done to incorporate a given set of changes consistently into a given software product. In each program analyzed, the average name defined in an interface is used in 2 or 3 compilation units; the average interface is used in 7 to 25 units. Thus if a programmer were to change a single name chosen at random from an arbitrary interface and then, like the UNIX tool make, compile every compilation unit using that interface, we would expect between 6 and 9 out of every 10 compilations to be unnecessary. This phenomenon extends to the purposeful changes made during program development. For historic changes made to one program, fewer than half the compilations performed after an interface change were actually necessary, even though the data was treated conservatively both by grouping changes and by eliminating spurious interconnections. This work corroborates practical experience as well as observations made by other researchers, solidly tying together a collection of disparate evidence into a coherent picture of software manufacture. It validates the approach taken by some programming environments to use an underlying flat (i.e. non-modular) representation of program objects and, to the extent that recompilation costs reflect general program complexity, leads us to question some basic assumptions about modularization. ftn*This research was sponsored in part by a Xerox Special Opportunity Fellowship and in part by the Defense Advanced Research Projects Agency (DOD), ARPA Order No. 4976, Amendment 20, under contract number F33615-87-C-1499, monitored by the Avionics Laboratory, Air Force Wright Aeronautical Laboratories, Aeronautical Systems Division (AFSC), United States Air Force, Wright-Patterson AFB, Ohio 45433-6543. The views and conclusions contained in this document are those of the author and should not be interpreted as representing the official policies, either expressed or implied, of the Xerox Corporation, the Defense Advanced Research Projects Agency or the US Government.