Updating a Big State Fast in Haskell

Question

For my vector graphics library in Haskell I must carry around a rather big state: line stroke parameters, colors, clip path etc. I know two ways of doing this. Quoting a comment

Answer 1

First of all I have to ask are you just claiming it's going to be slow or did you profile or at least notice a performance issue? otherwise guessing or making assumptions isn't particuarly useful. Anyway I recommend grouping your data, at the moment it looks like you're just laying out your structure completely flat when you could group related data like the data related to lines into records.

You might also want to seperate out bits that really need to be in the state monad and others that don't into a reader/writer monad and combine them using monad transformers. Regarding elegance of code I'd recommend using (first-class/higher-order) record libraries like fclabels.

I've made heavy use of state monads (in a stack of a monad transformer) in a few small projects and I haven't noticed any performance issues yet.

Lastly you could use modify instead of a get/put pairs.

Answer 2

Even with quite a few fields in your record, "creating a new one" just means copying pointers. And "letting the old one be garbage collected" just means releasing a few bytes for each pointer in a way that GHC's generational garbage collector is very fast at handling. It all boils down to a handful of machine instructions. So even for a graphics application, that very well may not kill your performance at all.

If you are sure that it really does impact on performance, organize the fields into a tree. You can create a fixed-shape tree by using nested data types, or even just use Data.IntMap. That will get you an average of log n / 2 pointer copies. You can do even better if you know that certain fields are accessed much more often.

It would be a very rare application whose state is so complex and whose performance requirements are so heavy that the only option is STRef fields. But it's nice to know that the option is there.

Answer 3

As an aside, you should certainly be improving your data type representation via unboxing, if you are concerned about performance:

data GfxState = GfxState {
  lineWidth :: {-# UNPACK #-}!Double,
  lineCap   :: {-# UNPACK #-}!Int,
  color     :: {-# UNPACK #-}!Color,
  clip      :: Path,
  ...
}

By unpacking the constructors, you improve the density of your data, going from a heap structure like this:

to the denser, stricter:

Now all the atomic types are laid out in consecutive memory slots. Updating this type will be much faster! BTW, 461.. is the Word representation of the pi field, a bug in my viewer library

You'll also reduce the chance of space leaks.

The cost of passing such a structure around will be very cheap, as the components will be stored in registers.