Trends in Profiling Haskell

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.

Posted in Haskell | 5 Comments

Twilight Hero

Hero fights off recreant using the new melee rule mechanics for roguestar.

Here we see our hero fighting a recreant with a kinetic sabre. The material spheres front and left can be used to repair yourself, while a phase rifle is to the right. In unskilled hands, such powerful weapons can more dangerous to the user than enemy.

Posted in Roguestar | Leave a comment

MaybeArrow?

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.

Posted in Haskell | 10 Comments