[Haskell-cafe] Battling laziness

[Simon Marlow]

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