Johannes Waldmann <johannes.waldm...@htwk-leipzig.de> writes: > 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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs