[Haskell] performance tuning Data.FiniteMap

S. Alexander Jacobson alex at i2x.com
Thu Feb 26 01:47:25 EST 2004

I know that array copy is much more expensive than
a single update.  But when you say:

On Wed, 25 Feb 2004, Simon Peyton-Jones wrote:
> Haskell's current story is to use O(log n) structures such as trees --

Yes, I got that.  The question is how I trade off
between reads and writes.  If I write very
infrequently I may be willing to pay for varying
levels of more arrayness (lower read time, higher
update time).

But in managing this tradeoff, what is faster:
* constructing/destructing e.g. 16 trees (for a 65000 item table)
* 2 memcpy of 256 item arrays (perhaps after you primop?)

If the later is not dramatically slower than I
will bias towards more arrayness.  In this
context, I believe that mmx insns in modern CPUs
dramatically accelerate in-cache memcpy.  If that
is the case, then e.g. 256 element arrays could
be optimal.

> You should feel no need to apologise.  Our community *needs* people like
> you, who are using Haskell for real applications.  That's how we'll
> learn "where the shoe pinches".   Ask away.

Thank you.


S. Alexander Jacobson                  mailto:me at alexjacobson.com
tel:917-770-6565                       http://alexjacobson.com

More information about the Haskell mailing list