[RFC] Compiler pipeline timings visualization

[Ben Gamari]

Andreas Klebinger <klebinger.andreas at gmx.at> writes:

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200501/aca618c6/attachment.sig>