[Haskell] performance tuning Data.FiniteMap
simonpj at microsoft.com
Fri Feb 27 09:20:40 EST 2004
[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!
| -----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?
| 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
| > to find out. And GHC is not doing as well as it should on arrays
| > 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
More information about the Glasgow-haskell-users