index

A Tip for Profiling GHC March 26, 2020

GHC developers are often in a situation where we want to profile a new change to GHC to see how it affects memory usage or runtime performance. In this post I will describe quite an ergonomic way of profiling any merge request without having to build the branch yourself from source or in any special mode. We’ll download the bindist from GitLab CI and then compile a simple GHC API application which models the compilation pipeline which we can profile.

An IDE implemented using reflex March 16, 2020

Around this point last year I set out to reimplement a lot of the backend of haskell-ide-engine in order to make it more easily usable with a wide variety of build tools. This effort was largely a success and my branch was merged just before Christmas thanks to the extensive help of Zubin Duggal, Fendor, Alan Zimmerman, Luke Lau and Javier Neira. The main result was an IDE based on the hie-bios library which abstracts the interface to the different build tools so the IDE itself doesn’t have to worry about how to set up the GHC session.

Since then, the situation is vastly different with the focus now turning to ghcide and hls. ghcide is generally faster and more robust than haskell-ide-engine because it reimplements certain parts of the GHC API which allow for finer grain recompilation checking. The future extension, hls, will extend ghcide with support for code formatters and other diagnostics. I have found implementing extensions to ghcide much easier and more robust. Both ghcide and hls are built on top of hie-bios.

At Munihac 2019, Neil Mitchell gave a presentation where he described the motivation for ghcide and a general description of the architecture. In his talk, he describes how you can think of an IDE as a dependency graph, which was greeted by an audience heckle suggesting an FRP library could be used to implement the IDE. The current implementation is based on shake, which has similar properties to an FRP library but with some crucial differences.

The pull-based model of shake does not scale well to large code bases. All requests scale linearly with the number of dependencies which means that even requests such as hovering can take upwards of 1s on a module with a large number of transitive dependencies. A 1s hover response time was enough to get me interested and after attempting to improve the performance I decided that without a fundamental rewrite, the situation could not be improved.

So spurred on by the heckle and the desire for subsecond reponse times it was time to put the money where my mouth was and attempt to reimplement the backend using reflex instead of shake. Reflex is push-based which means once the network is constructed changes propagate from input events rather than being pulled from samples. This seemed like a better model for an IDE.

What did I imagine the primary benefits to this project would be?

I wanted to prove it was possible.
Using the push-based model means that requests such as hovering can return instantly rather than checking to see if any dependencies have updated.
Handlers for LSP requests can be written in the same language as the functions which computed the module graph.

In short, I now have an IDE which works and is completely implemented using reflex which gives you a point to be able to evaluate the costs and benefits to both approaches.

In this post I will describe some of the basic abstractions which I implemented using reflex which gives writing the IDE a similar feel. The rest of this post is aimed at people who are already familiar with reflex and goes into a reasonable amount of detail about specific things to do with reflex and design decisions I had to make.

Introducing hs-speedscope - a way to visualise time profiles November 7, 2019

In GHC-8.10 it will become possible to use speedscope to visualise the performance of a Haskell program. speedscope is an interactive flamegraph visualiser, we can use it to visualise the output of the -p profiling option. Here’s how to use it:

Run your program with prog +RTS -p -l-au. This will create an eventlog with cost centre stack sample events.
Convert the eventlog into the speedscope JSON format using hs-speedscope. The hs-speedscope executable takes an eventlog file as the input and produces the speedscope JSON file.
Load the resulting prog.eventlog.json file into speedscope.app.

Announcing Bristol Haskell Hackathon 2020 October 21, 2019

I have decided to organise an informal hackathon in Bristol at the start of next year.

When	25th-26th January 2020
Where	Merchant Venturers Building - University of Bristol
Time	09:00 - 17:00

Anyone interested in Haskell is welcome to attend. Whether you are a beginner or an expert it would be great to meet you in Bristol.

It is a no-frills hackathon, we’ll provide a room for hacking and wifi but expect little else! There will be no t-shirts, food, talks or other perks. The focus will be 100% on hacking and meeting other Haskell programmers.

For further information about the event and how to register please refer to the dedicated page.

Two new Haskell Symposium papers July 9, 2019

This year I was lucky to have both my papers accepted for the Haskell Symposium. The first one is about the problematic interaction of Typed Template Haskell and implicit arguments and the second, a guide to writing source plugins. Read on the abstracts and download links.