Dilemma: DiffArray non-performance vs STArray non-readability

Claus Reinke claus.reinke at talk21.com
Mon Oct 27 14:10:25 EDT 2008


I keep wanting to use DiffArray as the natural functional solution to
single-threaded array use. But everytime I try, I get smacked over
the head with the actual performance figures. Sometimes, even plain
arrays are faster in a loop doing array updates, in spite of all the 
copying involved. And when copying on update dominates the runtime, 
using IntMap tends to be faster - the "indirections" are the wrong way
round, but don't pile up, just that array lookups aren't quite constant
time.

But when I really need to avoid the updates, and need constant
time lookup, I'm stuck: DiffArray tends to slow everything down
(I vaguely recall locks and threads being at the heart of this, but
I haven't checked the code recently), so my only option seems to
be to transform my nice functional code into not-nice sequential 
code and use STArray.

Is there any way out of this dilemma? What do other Ghc users use?

If locks really are the issue, perhaps using STM instead of MVars
in the DiffArray implementation could help. As long as my array 
uses are single-threaded, STM optimism might be able to avoid
waiting/scheduler issues? Or am I on the wrong track?

Claus

PS Btw, I thought the DiffArray performance issue was ancient,
        but I can't find a ticket for it, nor does the haddock page for
        Data.Array.Diff mention this little hickup. Should I add a ticket?




More information about the Glasgow-haskell-users mailing list