[GHC] #10739: Resuscitate the humble ticky-ticky profiler

[GHC]

#10739: Resuscitate the humble ticky-ticky profiler
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Profiling         |              Version:  7.10.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #8308, #9405      |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 I've spent much of today trying to correlate Ticky's results with the
 RTS's allocation counters and at this point I strongly suspect that there
 is a rather large discrepancy. Specifically, I've been trying to track
 down an apparent regression in `haddock`'s allocations due to Phab:D2038.
 Here I observe,

 ||=  =||= Ticky's `ALLOC_HEAP_ctr` =||= Ticky's `ALLOC_HEAP_tot` =||= RTS
 `Bytes allocated` =||
 || *before D2038* || 174007560 || 9357869592 || 23809691712 ||
 || *after D2038*  || 174243649 || 9365165304 || 27690978448 ||

 That is, while the RTS's `bytes allocated` metric regresses by around 15%,
 Ticky's allocation counter only appears to regress by ~1%. Moreover, I am
 unable to find any large regression in the per-closure counters. It's all
 very unfortunate.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10739#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler