We describe the design, implementation and use of a new kind of profiling tool that yields valuable information about the memory use of lazy functional programs. The tool has two parts: a modified functional language implementation which generates profiling information during the execution of programs, and a separate program which converts this information to graphical form. With the aid of profile graphs, one can make alterations to a functional program which dramatically reduce its space consumption. We demonstrate this in the case of a genuine example --- the first to which the tool was applied --- for which the results are strikingly successful.

The context for this paper is functional computation by graph reduction. Our overall aim is more efficient use of memory. The specific topic is the detection of dormant cells in the live graph --- those retained in heap memory though not actually playing a useful role in computation. We describe a profiler that can identify heap consumption by such `useless' cells. Unlike heap profilers based on traversals of the live heap, this profiler works by examining cells postmortem. The new profiler has revealed a surprisingly large proportion of `useless' cells, even in some programs that previously seemed space-efficient such as the boot-strapping Haskell compiler nhc. 1 Introduction A typical computation by graph reduction involves a large and changing population of heap-memory cells. Taking a census of this population at regular intervals can be very instructive, both for functional programmers and for functional-language implementors. A heap profiler [RW93] records population counts for ...

Introduction Excessive requirements for memory space have in the past hindered or even prevented otherwise attractive applications of functional programming. Although this could be blamed in part on space-hungry implementation methods, in most cases it would have been possible to cut memory requirements very significantly by making a few changes to the source program. But there were no tools to help programmers make appropriate changes. Usage of heap memory was reported only as a total volume of allocations; there was no way to investigate how different parts of a program made demands on heap memory --- something which may be far from apparent in the source of a sizable program making use of lazy evaluation and higher-order functions. Finding the appropriate place to make a space-saving change could be very difficult. In the last few years, there has been a renewed effort to provide appropriate profiling tools for functional programmers. Because the first aspect of performance

Lazy functional languages seem to be unsuitable for programming small computers because their implementations require so much memory for program code and graph. In this paper we argue that the program code can be made much smaller (withoutrunning much slower) by using the old idea of throw-away compilation. Our first results are promising --- programs using throw-away compilation typically run at 75% of the speed of those with ordinary compilation, but require only 25% of the code space. 1. Introduction Today computers lurk everywhere, heavily disguised as digital diaries, mobile telephones, video cameras and countless other electronic devices. However, it is most unlikely that any of these covert computers was programmed with a functional language. Traditionally, the execution speed of functional programs has been abysmal, and their memory requirements have been absurd. Yet two characteristics of the market lead us to believe that functional languages may one day be used to program c...

Mere academic toys or the tools of the future? Lazy functional programming languages have undoubted attractive properties. This thesis explores their potential, from the programmer's point of view, for implementing interactive and graphical applications to which they do not seem immediately suited. The discussion is centred round two example applications. One is a graphical design program based on an idea of the artist M. C. Escher. The thesis argues that the graphical user interface may be encapsulated in an "interpret " function that when applied by a mouse click to an interface of appropriate type yields the required behaviour. The second example is a monitoring interpreter for a functional language. The idea is that if the mechanics of the reduction are presented at a suitable level of abstraction, this may be used to give insight into what is going on. On the basis of this the programmer might modify the code so that a program runs more efficiently in terms of speed and memory requirements. Problems of displaying the reduction are addressed, and solutions proposed for overcoming these: displaying the graph as a spanning tree, to ensure planarity, with extra leaves

ion: Nets . . . . . . . . . . . . . . . . . . . . . 50 4.4.1 Net Signature . . . . . . . . . . . . . . . . . . . . . . . 51 4.4.2 Packet Signature . . . . . . . . . . . . . . . . . . . . . 53 4.4.3 Sequential Prototype for Nets . . . . . . . . . . . . . . 54 4.5 Functional Description of the Templates . . . . . . . . . . . . 55 4.5.1 Skeleton's Types in Haskell . . . . . . . . . . . . . . . 56 4.5.2 Sequential Templates . . . . . . . . . . . . . . . . . . . 57 4.5.3 Distributed Templates . . . . . . . . . . . . . . . . . . 58 4.6 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.7 A Comment about Expresiveness . . . . . . . . . . . . . . . . 65 4.7.1 From 1 packet to N packets . . . . . . . . . . . . . . . 65 4.7.2 From N packets to 1 packet . . . . . . . . . . . . . . . 67 4.8 Conclusions and Future Work . . . . . . . . . . . . . . . . . . 68 5 Final Conclusions and Future Work 71 Bibliography 75 Introduction Chapter 1 Introduction Functional Programming [BW8...

Introduction This chapter initially considers pure lazy functional languages: their philosophy, advantages and disadvantages. We then examine how to develop efficient lazy functional programs. One way to achieve efficiency is to introduce impurities. In the final section the two schools of lazy functional programming, pure and impure, are assessed. The assessment centres around two partial implementations of the Hopcroft Tarjan graph planarity algorithm. Profiling tools are used to make an experimental comparison and optimisation of each program. 4.1 Lazy Functional Programming In his book [42] Reade suggests that the user of a traditional imperative language is required to do the following: 1. describe the result to be computed; 2. impose an order on the steps required in the computation; 3. create and destroy, as required, any data structures used by the computation. 74 The first item is concerned with the extensional prope