@lexi_lambda: How to make a Haskell program 5x faster with 16 lines of code

I just saw this great video by Alexis King about optimizing your Haskell programs:

Some of my personal takeaways:

  1. Start with a clear benchmark of two versions of your code where one is fast but unidiomatic and the other is more idiomatic but slow.
  2. Looking at Core is the first step, but not always helpful. Going through optimizations (e.g. inlining) by hand tells you more about the problem.
  3. Composition operators (e.g. >>> or >>=) are really important to produce optimized code. Make sure they optimize well.
  4. Rewrite rules are extremely useful for cases where the compiler can’t figure out obvious optimizations by itself and opportunities for these optimizations are the result of other common optimizations like inlining the composition operators.

I’m left with some ideas and questions:

  1. Can we make tools to make it easier to do this kind of analysis. For example a tool that lets you browse the code and click on a function to inline its definition (preferable one that warns you if GHC wouldn’t choose to inline that function).
  2. What happens if we would have dug further and also inlined paste and cut? Why couldn’t the compiler figure out these simple pastes? This also reminds me of “Rewrite rule inference using equality saturation”.

I also really enjoyed this video, but had similar questions. In particular, how much room is there for HLS integration to help inspecting core?