On Tue, Oct 10, 2006 at 01:59:23PM +0100, Ian Lynagh wrote:

To: Matthias Fischmann Cc: haskell-cafe@haskell.org From: Ian Lynagh Date: Tue, 10 Oct 2006 13:59:23 +0100 Subject: Re: [Haskell-cafe] Profiling CAFs (re-post)

On Tue, Oct 10, 2006 at 01:31:58PM +0200, Matthias Fischmann wrote:

...

What qualifies as constant applicable form, and why is it not labelled in a more informative way?

CAFs are, AIUI, things that are just values (i.e. things that don't take an argument) that have been floated up to the top level.

Ok, this is consistent with the documentation. However, it doesn't explain why we would need to treat them differently. In particular, I don't understand why I wouldn't want to know their (module-global) names.

Compiling with -caf-all might give you more useful information.

Oops. I thought i had that in my Makefile, but appearently i was wrong... If I add it, this is what happens: ====================================================================== module Main where x = f [1..5] (f [2..] [3..]) f xs ys = l where l = [ if s then x else y | (x, y) <- zip xs ys ] s = g xs ys g [] _ = True g _ [] = False g (x:xs) (y:ys) = g xs ys main = print (show x) ====================================================================== $ ghc -prof -caf-all Main.hs -o Main # (ghc 6.4) /tmp/ghc22775.hc:1475: error: redefinition of `Mainmain_CAF_cc_ccs' /tmp/ghc22775.hc:1470: error: `Mainmain_CAF_cc_ccs' previously defined here /tmp/ghc22775.hc:1490: error: redefinition of `Mainsat_CAF_cc_ccs' /tmp/ghc22775.hc:1480: error: `Mainsat_CAF_cc_ccs' previously defined here /tmp/ghc22775.hc:1495: error: redefinition of `Mainsat_CAF_cc_ccs' /tmp/ghc22775.hc:1490: error: `Mainsat_CAF_cc_ccs' previously defined here $ ghc -prof -auto-all -caf-all Main.hs -o Main /tmp/ghc22771.hc:1517: error: redefinition of `Mainmain_CAF_cc_ccs' /tmp/ghc22771.hc:1512: error: `Mainmain_CAF_cc_ccs' previously defined here

If that doesn't help then you might find it helpful to look at heap profiles rather than just the normal profiler output.

Section 5.4, prof.hp, yes. Probably should have thought of that myself. Will do.

...

Why are there functions that inherit all of their (considerable) time and space consumption from elsewhere, but nothing in the list would allow for such a rich inheritage?

I didn't understand that. If it's possible to give a small example then that might help?

Small is harder in this case than with type errors. But I'll try as soon as I know what's wrong with the above. thanks, matthias

On 10/10/06, Ian Lynagh wrote:

On Tue, Oct 10, 2006 at 01:31:58PM +0200, Matthias Fischmann wrote:

...

What qualifies as constant applicable form, and why is it not labelled in a more informative way?

CAFs are, AIUI, things that are just values (i.e. things that don't take an argument) that have been floated up to the top level.

Actually, I don't know if this is a ghc bug but I was profiling last week and a majority of the time/allocation was done in a CAF in a module which didn't seem to be doing much work. Turned out in my case that the module in question imported a function from another package which was doing a tremendous amount of work. It wasn't until I used -caf-all that I could see the real culprit. So, I guess a CAF can also be a function in a library you're using. And I say function here because the work horse definetly was not a CAF. It was hPutXml from HaXml. The lesson for me was that -caf-all is handy to know about. Jason