Hello GHC, Thursday, January 12, 2006, 5:52:28 PM, you wrote:
G> #650: Improve interaction between mutable arrays and GC G> This also affects IORefs, which are essentially single-element IOArrays. G> I just noticed that GHC often has a large number of IORefs hanging around G> in the heap from the typechecker, and the cost of traversing the mutable G> list can dominate minor GCs. Simon, i have another one solution of this problem: on EACH write to IOArray/STArray/IORef/STRef save an address of updated value in some list. then, on minor GC scan this list and promote values reachable from these array elements to the next generation this may be slower, but at least it will be "fair" solution - amount of additional work is directly proportional to number of writes, not the total size of all IOArrays i think that me must first collect examples of applications which really suffers from this problem, to be able to make well-founded solution. that i send you is just an artifical one (sorry, but it is very close to my real application, which works very fast except for these GCs), we can also add loop in descending order and loop in random order to these artifical bencmarks. real applications may be some working with HashTable and even GHC itself one more suggestion - may be GHC can be speed up by replacing IORefs by implicit parameters? it can also help to make GHC a library and to run several compilations in parallel on multi-core cpus -- Best regards, Bulat mailto:[EMAIL PROTECTED] _______________________________________________ Glasgow-haskell-bugs mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
