ANNOUNCE: GHC 7.4.1 Release Candidate 1

Simon Marlow marlowsd at
Tue Jan 3 12:00:58 CET 2012

On 21/12/2011 22:36, Roman Cheplyaka wrote:
> * Ian Lynagh<igloo at>  [2011-12-21 18:29:21+0000]
>>    * The profiling and hpc implementations have been merged and overhauled.
>>      Visible changes include renaming of profiling flags:
>>      and the cost-centre stacks have a new semantics, which should in most
>>      cases result in more useful and intuitive profiles. The +RTS -xc flag
>>      now also gives a stack trace.
> Where can we learn more about the new semantics?

I haven't writtne down the semantics formally yet, I'm afraid, and it 
may yet change.  However, you should find that the changes give more 
intuitive results, and profiling is now more robust to compiler 

There are a few visible changes.  One is that -auto-all will label 
nested functions by default now (but you can revert to the previous 
behaviour of labelling only top-level functions with -fprof-auto-top).

Another visible change is that higher-order functions are now pushed on 
the stack when they are called, not when they are referenced.  For 
example, in "map f xs" you will see that map calls f, whereas previously 
f would be shown as a child of the function containing the call to map 

This also means that the costs of a calling a higher-order function are 
always part of the aggregate costs of the caller, rather than being 
attributed to the higher-order function itself.  For example, if you have

   f xs ys = {-# SCC "map1" #-} map g xs ++ {-# SCC "map2" #-} map g ys
     where g = ...

then you'll see that map1 calls g and map2 calls g, and the costs of 
calling g on the elements of xs are recorded separately from the costs 
of calling g on the elements of ys.  Previously all the costs of g would 
be attributed to g itself, which is much less useful.

I'd be interested in hearing feedback, particularly if you find a case 
where costs are attributed somewhere that you didn't expect, or the 
stack looks wrong.


More information about the Glasgow-haskell-users mailing list