#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