[Haskell] performance tuning Data.FiniteMap

[Simon Peyton-Jones]

[Moving to GHC users list]

There are several things that aren't research issues: notably, faster
copying, fewer intermediate lists, fewer state-monad-induced
intermediate closures.  These are things that would move sharply up our
priority list if you had a real application that was stumbling on them.

What I obviously can't promise is that improving these things would
solve your problem -- if, indeed, you turn out to have one!

Simon

| -----Original Message-----
| From: S. Alexander Jacobson [mailto:alex at i2x.com]
| Sent: 26 February 2004 23:27
| To: Simon Peyton-Jones
| Cc: haskell at haskell.org
| Subject: RE: [Haskell] performance tuning Data.FiniteMap
| 
| Is fixing GHC arrays a big research job or is it
| something that someone can straightforwardly
| handle if my site actually gets enough traffic to
| warrant it?
| 
| -Alex-
| 
| On Thu, 26 Feb 2004, Simon Peyton-Jones wrote:
| 
| > | 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.
| >
| > I doubt the latter is dramatically slower, but you'd have to
experiment
| > to find out.  And GHC is not doing as well as it should on arrays
just
| > now.  (One of the things on our to-do list.)  Might vary between
| > implementations too.
| >
| > Simon
| >
| 
| _________________________________________________________________
| S. Alexander Jacobson                  mailto:me at alexjacobson.com
| tel:917-770-6565                       http://alexjacobson.com