Online self-access learning system for database query processing

Abstract

Software build systems play an important role in program developing. However its importance has long been neglected by developers until the source programs get too large to be built in a short time. As the evolution of hardware, computers are getting more and more powerful computing powers. However some big projects still require a long rebuild time. The reason is that when these big projects grew from very small project to their current size, build system also evolved with source codes in order to build these program correctly. However, for most cases, build performance decays during evolution. Certain maintenance work could be invested on build system as with its evolution to improve the build performance. McIntosh et al. found in that the bottle-neck of build performance improvement is located at hotspot files. Build hotspot files, as defined as header files that triggers long rebuild time, and at the same time, changes in a relatively frequent manner, are the main concern of this project. This project replicates the methodology of built hotspots identifying process of McIntosh et al.'s previous work, in phase one. However, since they found some

aws in costliness comparing method in, and proposed a brand new way of comparing file cost in their latest work, we did not have enough time to keep up with the new method. However a series of interesting findings were observed in the evolutionary studies of build hotspots, which is the goal of second phase of this project. Here is a snapshot of our findings: The rebuild times for all files in a list of consecutive versions of the same project, actually goes up unless refactoring is encountered. Build hotspots are sticky, which means once a file falls in build hotspot zone, it has higher chance continuing to be hotspot file rather than falling back to non-hotspot files.