6

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.

insitu
  • 4,488
  • 3
  • 25
  • 42
  • https://stackoverflow.com/questions/35375143/haskell-debugging-long-compilation-times-on-stack-projects – leftaroundabout Nov 23 '17 at 15:01
  • 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 Nov 24 '17 at 17:13

2 Answers2

2

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.

tom
  • 958
  • 6
  • 17
0

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

MathematicalOrchid
  • 61,854
  • 19
  • 123
  • 220
  • Thanks. I think I have an emrbyonic solution which would be based on `-dshow-passes` which dumps some statistics per module (and yes, I meant 70 modules because I am interested in knowing which modules take the most time, it's easier for packages). I have started to write some very simple tool to extract that information from build and dump statistics. – insitu Nov 24 '17 at 17:16