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 Answers
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.
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...
Related