Richard Eisenberg
Thanks for all the responses. Yes, I'm looking for the number of allocations of a constructor; this is an allocations issue, not a retention/liveness issue. I'm not concerned about accesses (not even sure what that would mean). Adding this to -ticky would be very helpful -- and not just for me. For example, it would help us to know more precisely why !2249 (implementing BoxedRep) is mired in performance trouble: we could see how many more TyConApp nodes are created.
If this would be easy, is there someone who can guide me how to implement it? I am almost as clueless as someone who has never before gazed on GHC's code in these areas. (Or, I would be grateful for someone else to implement it, too.)
Actually, looking more closely at the implementation of ticky, it looks like we *do* track DataCon allocations (the giveaway was the mention of withNewTickyCounterCon in GHC.StgToCmm.Bind.cgRhs). For instance, let con = Just x in ... would produce a ticky counter named "con". The problem is that there is no convenient way to get from the Id name (e.g. `con`) back to the datacon that it allocates (e.g. `Just`). You could of course try to parse this out of -ddump-stg output but... yuck. Perhaps the ticker name should preserve this information. I've pushed a completely un-build-tested attempt at this as !3340. Like most of ticky's output, it won't be the easiest thing to mechanically parse but it should be possible. Cheers, - Ben