profiling a constructor?

Ben Gamari ben at
Sun May 24 04:24:40 UTC 2020

Richard Eisenberg <rae at> writes:

> 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.


- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <>

More information about the ghc-devs mailing list