Correlating GHC Cost-Center Profiles with ThreadScope Eventlogs for Unified Bottleneck Analysis

Currently, there is no released version of GHC or a stable third-party tool that automatically binds cost-center identifiers to individual eventlog records. Cost-center profiling (.prof) provides aggregate statistics over the program's lifetime, while the eventlog (.eventlog) provides a chronological trace of runtime events. These two streams operate independently and lack a shared correlation ID.

Likely Explanation of the Gap

The primary obstacle is performance overhead. Embedding a full cost-center stack into every eventlog record (such as thread migrations or GC starts) would exponentially increase the size of the eventlog and likely introduce prohibitive latency. Furthermore, because Haskell is lazy, the cost-center associated with a thunk's creation is often distinct from the cost-center active when that thunk is forced, making a simple "tag" insufficient for accurate attribution in a concurrent environment.

Implementation for Manual Correlation

Since a native unified profile does not exist, the most reliable workflow for GHC 9.6+ is to use user-defined event markers to create synchronization points between the two data sources.

1. Instrument Code: Use the GHC.Eventlog module to insert named markers at the entry and exit of suspected bottleneck functions.
2. Compile and Run:

   ghc -threaded -prof -fprof-auto -eventlog Main.hs
   ./Main +RTS -N -p -l

3. Analyze:
   • Open the .prof file to identify the top cost-centers by time or allocation.
   • Open the .eventlog in ThreadScope. Search for the custom markers inserted in step 1 to locate those specific cost-centers on the timeline.
   • Observe the thread scheduling and GC behavior specifically during the intervals bounded by your markers.

Potential Runtime Changes for Native Integration

To implement this natively without prohibitive overhead, GHC would likely need to adopt a sampling-based approach rather than an event-based one. Instead of tagging every event, the runtime could periodically sample the current cost-center stack and emit a CostCenterSample event to the log. This would provide a statistical correlation between the timeline and the profile without bloating the eventlog file.

Missing Diagnostic Detail: Are you observing bottlenecks primarily in the allocation rate (memory pressure) or in thread synchronization/latency? If the issue is purely allocation-based, -hT (heap profiling) may provide better spatial correlation than the eventlog.