>>> now i see what you mean. no, i mean trivial transformation. #650 says >>> about slow GC. why it's slow? because once you made any update to the >>> array, the entire array is marked as updated and scanned on next minor GC >>> (which occurs after every 512 kbytes allocated, afaik). let's replace >>> big array (say, of 10,000 elements) with array of 100 arrays of 100 >>> elements each. now, between minor GCs only some of arrays will be >>> changed and entire amount of memory to be scanned will become less >> Data.IntMap? > I want to implement a more-or-less traditional, mutable, imperative > hash table in the ST monad. Hence, I'm not considering Data.IntMap > and other persistent tree structures for its implementation, although > I have thought about it. > The bug described in Ticket #650, AFAICS, prevents implementation of a > reasonable, generic hash table in Haskell. :-(
Data.IntMap is just a limit of what Bulat suggested. So what was you thoughts about Data.IntMap in mutable hashmap? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
