Is there a way to profile compilation time per module with GHC?

6
votes

I think everything's in the title, but to give more context. We have two 70+ packages whose compilation times are pretty different: One takes twice as much time as the other (without taking into account parallelization). I would like to know which modules take the most time in order to have a better understanding of what is causing this discrepancy.

2
haskellghc
stackoverflow.com/questions/35375143/… – leftaroundabout
yes, seen that question but there is no answer beside some general advice on how to make GHC faster... Or maybe I read it too quickly? – insitu

2 Answers

1
votes

GHC can output per-module timing data nowadays when you build with -ddump-to-file -ddump-timings. This causes files with the extension .dump-timings to be written in your build directories (generally .stack-work for Stack and dist-newstyle for Cabal).

I wrote a tool to find all these files and visualize them: https://github.com/codedownio/time-ghc-modules.

0
votes

Not sure if you means 70+ packages or 70+ modules, but anyway...

I can't think of any particularly easy way to do this. You could try to time exactly when GHC writes its messages to the console; I'm not sure how accurate that would be. Otherwise, I guess you'd have to figure out the correct compilation order, and invoke GHC manually to compile one module at a time, and use OS-level tools to time how long each compile command takes. (Perhaps GHC's automatic Makefile generation feature could help...)

It is possible to compile GHC itself with profiling enabled, but I don't think that helps in this case. (And it's quite a lot of work.)

FWIW, I too would like to know why some modules take a small eternity to compile while others are almost instant...