Lane's Blog

I spent some time yesterday profiling roguestar. I do this every few months just to see where things stand, and there are always two culprits at the top of roguestar-gl.prof, every single time:

* typeclass dictionary lookups in inner loops
* Rational

In the first case, I think the simplest solution is to INLINE the puppy. Can the ghc inliner be a little bit more aggressive when it sees dictionary lookups? Inliners are tricky business. I’m not sure I see a simple heuristic. Vaguely: leaf functions that require dictionary lookups need to be specialized.

Rational can sneak into an unsuspecting program through realToFrac, and absolutely *kills* performance.

I sit down thinking to myself, “Ok, today I’m going to streamline my Super Mumbo Jumbo Widget and get 15% faster performance,” or some such goal I set for myself. And I run the profiler and 75% of my time is being spent in fromRational . toRational.

As I’ve found myself repeatedly writing a bit of code that looked vaguely like this:

get :: SomeArrow String (Maybe Thing)

foo :: [Thing] -> FooThing

. . .

getAToZ :: SomeArrow () (Maybe FooThing)
getAToZ = proc () ->
    do m_a <- get -< "a"
       m_b <- get -< "b"
       . . .
       m_z <- get -< "z"
       returnA -<
           do a <- m_a
              b <- m_b
              . . .
              z <- m_z
              return $ foo [a,b . . . z]

It seemed that there would have to be a way to automate this. So I wrote this MaybeArrow (careful, I'm still using 6.8.2 so it's the old arrows with 'pure'.). I know that there is already an ErrorArrow. But ErrorArrow as far as I can see requires ArrowChoice, and I'm not doing that. In the MaybeArrow, if an earlier computation throws a Nothing, then later computations are still allowed to perform side effects, although their outputs are snuffed, which is the behavior I want.

I would appreciate any constructive feedback.

If you're wondering the use case has to do with waiting on several separate pieces of information to arrive from a server and combining them into one output message.

Donald Knuth says: If people do discover nice ways to use the newfangled multithreaded machines, I would expect the discovery to come from people who routinely use literate programming.

This is called Haskell.

(++) is basically `mappend`.

(.) is basically `fmap`.

Others?

I’m told that (++) originally was `mappend`, but it was specialized to avoid confusing the newbies. I’m not going to waste bytes arguing with consensus formed before I knew the language existed, but I disagree.