9 Haskell data and code at run time

Haskell performance is a tricky story. It may be difficult to predict and explain, and it’s not the easiest thing to achieve in our programs. With functional and other declarative programming languages, code running on actual hardware tends to be much further from code written by a programmer than in the case of imperative languages. One of the consequences of this fact is that a programmer sometimes has a somewhat limited ability to affect performance directly. Although it is considered a task for a compiler to produce the best executable code possible, this goal is crucial for a developer also. Haskell laziness adds much to this intricacy. A programmer should be able to predict what is executed and what is not. Thanks to laziness, significant parts of the code may well not be evaluated at all.

9.1 A mental model for Haskell memory usage at run time

9.1.1 General memory structure and closures

9.1.2 Primitive unboxed data types

9.1.3 Representing data and code in memory with closures

9.1.4 A detour: Lifted types and the concept of strictness

9.2 Control over evaluation and memory usage

9.2.1 Controlling strictness and laziness

9.2.2 Defining data types with unboxed values

9.3 Exploring compiler optimizations by example

9.3.1 Optimizing code manually

9.3.2 Looking at GHC Core

Summary