Problems & Proposals for Time & Space Profiling of Functional Programs

Abstract

Many functional programs are quick and concise to express but large and slow to run. A few critical parts of the program may account for much of the time and space used: replacing these with something cheaper, or applying them less often, significantly improves overall performance of the program. The repetition of this refinement process, starting from a deliberately artless prototype, is a popular strategy for software development. But its effectiveness depends on the ability to identify the “critical parts”, and this is far from easy in a lazy functional language. Commenting on the experiences of a colleague developing a large application with their LML system, Augustsson and Johnsson note that

After long and painful searching in the program he finally found three places where full laziness was lost, each of which accounted for an order of magnitude in time (and it is not guaranteed that all such places were found) ... If a program does not run fast enough it can be quite difficult to find out why [1].