Andreas Klebinger
Hi Sergej,
I think this is a good idea in general, and it seems you did some great work there already. Something like this can also help with pinpointing performance issues inside the compiler so would not just be useful to end users.
intuitively I would assume that instead of adding another way to produce compiler events we should: * Ship GHC with eventlog enabled by default
For what it's worth, I have also been thinking about proposing this. I've been doing a lot of performance characterisation recently where I would have liked to use our binary distributions. Sadly this isn't an option as the ghc executable doesn't support the eventlog. I've not taken measurements on the eventlog overhead in ghc-bin but I suspect that any overhead that *does* exist can be easily eliminated (as I describe in #17949). We just need to ensure that Debug.Trace.{traceEvent,traceMarker} know not to pack their buffers if their respective tracing flags aren't enabled. Frankly, I also question the value of shipping the non-tracing-enabled RTS at all. Enabling tracing by default would allow us to eliminate three whole RTS builds from CI, which I suspect would be worthwhile. The size overhead on a statically-linked executable appears to be fairly small in the grand scheme of things: -rw-r--r-- 1 ben users 6.0M Apr 26 15:11 libHSrts-1.0.a -rw-r--r-- 1 ben users 6.4M Apr 26 15:21 libHSrts-1.0_l.a