1.2. Triage

This is a triage; it is the signpost that marks the start of your journey and should give you enough direction to make your next steps.

1.2.1. Symptoms

You do not have a problem, but want to learn performance-oriented Haskell

Begin with the Philosophies of Optimization. Then read the the programs of consistent lethargy, and some of the case studies. This should give you enough to decide your next steps. If you decide to begin doing some optimizations see the checklist for more ideas.

You have a performance regression that you want to understand and fix

You need to diagnose the regression and begin thinking in terms of an investigation. Read how to debug to make sure you know how to make progress. Since you have observed a regression, try to find a commit or state in your project where you do not observe the regression. This will let you bisect your project to narrow down the space of changes that START. You may also consider other forms of profiling and observation, such as:

• Running a tickyticky profile.

• Checking the heap.

• Inspecting the Core.

• Inspecting the STG.

• Observing the cache behavior.

• Observing the CPU’s Performance Counters.

You have a program that you want to begin optimizing

If you are short on time, begin with the checklist and then check for memory leaks. If not, begin with the easy changes:

• Use better datastructures.

• Carry checks in the type system so that the program is not always checking the same predicates.

• Filter before you enter a hot loop.

• Remove niceties in the hot loops, such as logging.

• Check the heap. The klister case study is a good example of this kind of optimization.

Then move into the more invasive changes such as:

• unrolling your monad transformers.

• Using the one-shot monad trick.

• Selectively defunctionalizing critical functions.

• Critically analyzing your architecture from a performance perspective.

You have a program that you’ve optimized, but want to optimize more

If you have already harvested the low hanging fruit then you have likely driven the program into a local maxima. Therefore, if you still need more speed then you must make more invasive changes, such as we listed above. However, the best changes you can make will exploit properties of the problem domain to reduce the work your program must do to arrive at a result. Often times these will be architectural changes.

Todo

In lieu of having links for you continue in this case. You can search for data-oriented design to begin refactoring your system in this manner. I highly recommend this this talk by Andrew Kelley.