In response to the two suggestions, I've linked my directory to:

http://www.isi.edu/~hdaume/haskell/NewBinary

I've made one or two small changes, the new version is attached. Summary: according to my rough measurements, the byte version is 2.5 times faster than the bit version (using your SpeedTest{Bits,Bytes}, with BinMem rather than BinIO). Compile it with -O -funbox-strict-fields. The library was designed with -funbox-strict-fields in mind (sorry I should have put a prominent comment to that effect somewhere in the source). It makes a *big* difference, especially to BinMem.

In there you will find FastMutInt, which is (almost) unchanged, Binary.hs which contains the new bit-based stuff, and a few test programs. You will also find profiles for bits and bytes (only 100000 elements this time, but there's still a huge discrepancy between bits and bytes) in:

bits_io_p.prof bytes_io_p.prof

One thing that immediately surprises me looking at the profile information is that the bits version allocates 200m more heap than the bytes version.

The discrepancy is still about 200M with my version. I haven't delved into the code that the compiler generates for putBits yet, so I imagine we can probably cut this down by quite a bit. The idea is that putBits should allocate nothing (I believe putWord8 has that property).

I have a function in FastMutInt for or-ing them. The comment next to it says "we should optimize this: ask SimonM :)", so I am asking SimonM now for a version which looks like incFastMutIntBy and hopefully uses unboxed or. Nevertheless, this only accounts for 1% of the time, so it's probably not a big deal.

These functions are fine, the compiler does a good job here. I'll take a closer look if I get a chance later. Cheers, Simon