Time-profiling the compiler pipeline

Sergej Jaskiewicz jaskiewiczs at icloud.com
Wed Feb 26 08:32:41 UTC 2020


Hello everyone,

Recently I've been exploring ways to improve the LLVM support in GHC.

While doing that, I've encountered an issue that I think is worth looking into.
Namely, the compilation times with LLVM are considerably longer than with the native
code generator. To be more concrete, on my machine I've managed to build
the whole toolchain in just half an hour with NCG, but the same build with
LLVM-powered GHC took several hours.

If we want to improve compilation times, we should be able to measure it first.
As far as I understand, the only way for profiling the compiler pipeline today
is building GHC with special flags: https://gitlab.haskell.org/ghc/ghc/wikis/debugging/profiling-ghc

This has three important downsides:
   * We need build the whole compiler ourselves. If I'm just a user interested in why
     my program is so slow to compile and how I should fix it, this is too much for me
     to ask to do.
   * There's just too much irrelevant data in the output. For example, it doesn't
     tell me which part of my Haskell code is taking so long to compile.
     It would be nice if the report contained all the metadata that I need to
     go and fix my code.
   * If we're using LLVM, we're pretty much out of luck, because we're using
     an existing LLVM binary which is likely not built for profiling.

There have been the same problem with the Clang compiler until recently. In Clang 9,
which was released in the last year, there's a new flag '-ftime-trace' that produces
a beautiful flame chart with all the metadata needed to identify bottlenecks.
This flag tells Clang to produce a JSON file that can be visualized
in Chrome's chrome://tracing page, or on https://www.speedscope.app.
This is described in more details here:
https://aras-p.info/blog/2019/01/16/time-trace-timeline-flame-chart-profiler-for-Clang/

I'm thinking about implementing similar functionality in GHC.
One option would be to utilize the plugin infrastructure.

Maybe I'm missing something and there are better options?

— Sergej.


More information about the ghc-devs mailing list