On 16 December 2005 12:08, Joel Reymont wrote:

-hc points to script#9 below.

script (_, _, affid) (Custom (JoinedTable 0)) = do {-# SCC "script#8" #-}push "takeEmptySeat" $ {-# SCC "script#9" #-}takeEmptySeat Holdem affid [] {-# SCC "script#10" #-}return $ Eat $ Just Go

What takeEmptySeat does it call pickTable

takeEmptySeat game_type _ filters Go = do push "pickTable" $ pickTable game_type filters return $ Eat $ Just Go

It's hard to pick out the cause of a space leak from just a fragment of the program, but I'll try to give you some pointers. If script#9 is the cost center attached to all of your leaking heap data, then you're already a long way to finding the problem. It'll help even more to find out whether it is just unevaluated copies of "takeEmptySeat Holdem affid []", or something else (-hd, -hy will help here). Try +RTS -hy -hcscript#9, for example. One obvious thing to try is replacing the '$' before {-# SCC "script#9" #-} with '$!'. And similarly in takeEmptySeat.

Overall, -hc does not help me figure out where my data is being retained. My understanding is that I need to do -hbdrag,void fo rthat. I did not try -hd and -hy, they would only help me narrow down the producers, right?

Not necessarily; lag/drag/void only tells you about certain kinds of space leaks. It's another tool in the box, and quite often you can get away without it. Retainer profiling similarly. (I should say that we definitely plan to update these for STM, but it's not completely trivial (I checked). Volunteers definitely welcome).

My program seems to spend 70% of the time collecting garbage. Notice the HUGE overall allocations. This is my trying to launch 4k bots over 8 hours. Only 1k bots were launched and just 300 of those got to play. Maybe because they did not have time with all the garbage collection :-).

Note that your GC time is inflated quite a bit due to profiling (it makes every object larger). The plan to reduce GC time is, in this order: squash space leaks, reduce allocation (to reduce GC load), and then tweak GC parameters. Cheers, Simon