Formally Based Pro ling for Higher-Order Functional Languages

We present the rst source-level prooler for a compiled, nonstrict, higher-order, purely functional language capable of measuring time as well as space usage. Our prooler is implemented in a production-quality optimizing compiler for Haskell and can successfully proole large applications. A unique feature of our approach is that we give a formal speciication of the attribution of execution costs to cost centers. This speciication enables us to discuss our design decisions in a precise framework, prove properties about the attribution of costs, and examine the eeects of diierent program transformations on the attribution of costs. Since it is not obvious how to map this speciication onto a particular implementation, we also present an implementation-oriented operational semantics, and prove it equivalent to the speciication. 1. MOTIVATION AND OVERVIEW Everyone knows the importance of prooling tools: the best way to improve a pro-gram's performance is to concentrate on the parts or features of a program that are \eating the lion's share" of the machine resources Bentley 1982; Ingalls 1972; Knuth 1971]. One would expect prooling tools to be particularly useful for very high-level languages where the mapping from source code to target machine is much less obvious to the programmer than it is for (say) C. Despite this obvious need, prooling tools for such languages are very rare. Why? Because proolers can only readily measure or count low-level execution events, whose relationship to the under the title \Time and space prooling for non-strict, higher-order functional languages." original high-level program can be far from obvious. With this in mind, we have developed a prooler for Haskell, a higher-order non-strict, purely functional language Hudak et al. 1992]. We make three main contributions: (1) We describe a source-level prooler for a compiled, nonstrict language capable of measuring both execution time and space usage. Nonstrict languages are usually implemented using some form of lazy evaluation, whereby values are computed only when required. For example, if one function produces a list which is consumed by another, execution alternates between producer and consumer in a coroutine-like fashion. Execution of diierent parts of the program is therefore nely interleaved, which makes it diicult to measure how much time is spent in each \part" of the program. Our prooler solves this problem; indeed, though the results depend on the degree of evaluation, they are entirely independent of the order in which the evaluation proceeds. This issue has been independently addressed …