Johannes Waldmann
Hi Ben, thanks,
4. run the build, `cabal configure --ghc-options="-p -hc" $args && cabal build`
cabal configure $args --ghc-options="+RTS -p -hc -RTS"
Ahh, yes, of course. I should have tried this before hitting send.
You should end up with a .prof and .hp file.
Yes, that works. - Typical output starts like this
COST CENTRE MODULE %time %alloc
SimplTopBinds SimplCore 60.7 57.3 OccAnal SimplCore 6.0 6.0 Simplify SimplCore 3.0 0.5
Ahh yes. So one of the things I neglected to mention is that the profiled build flavour includes only a few cost centers. One of the tricky aspects of the cost-center profiler is that it affects core-to-core optimizations, meaning that the act of profiling may actually shift around costs. Consequently by default the the build flavour includes a rather conservative set of cost-centers to avoid distorting the results and preserve compiler performance. Typically when I've profiled the compiler I already have a region of interest in mind. I simply add `OPTIONS_GHC -fprof-auto` pragmas to the modules involved. The build system already adds this flag to a few top-level modules, hence the cost-centers which you observe (see compiler/ghc.mk; search for GhcProfiled). If you don't have a particular piece of the compiler in mind to study, you certainly can just pepper every module with cost centers by adding -fprof-auto to GhcStage2HcOpts (e.g. in mk/build.mk). The resulting compiler may be a bit slow and you may need to be just a tad more careful in evaluating the profile. It might be nice if we had a more aggressive profiled build flavour which added cost centers to a larger fraction of machinery of the compiler, which excluding low-level utilities like FastString, which are critical to the compiler's performance.
These files are always called ghc.{prof,hp}, how could this be changed? Ideally, the output file name would depend on the package being compiled, then the mechanism could probably be used with 'stack' builds.
We really should have a way to do this but sadly do not currently. Ideally we would also have a way to change the default eventlog destination path.
Building executables mentioned in the cabal file will already overwrite profiling info from building libraries.
Note that you can instruct `cabal` to only build a single component of a package. For instance, in the case of the `text` package you can build just the library component with `cabal build text`.
When I 'cabal build' the 'text' package, then the last actual compilation (which leaves the profiling info) is for cbits/cbits.c
Ahh right. Moreover, there is likely another GHC invocation after that to link the final library. This is why I typically just use GHC directly, perhaps stealing the command line produced by `cabal` (with `-v`).
I don't see how to build Data/Text.hs alone (with ghc, not via cabal), I am getting Failed to load interface for ‘Data.Text.Show’
Hmm, I'm not sure I see the issue. In the case of `text` I can just run `ghc` from the source root (ensuring that I set the #include path with `-I`), $ git clone git://github.com/bos/text $ cd text $ ghc Data/Text.hs -Iinclude However, some other packages (particularly those that make heavy use of CPP) aren't entirely straightforward. In these cases I often find myself copying bits from the command line produced by cabal. Cheers, - Ben