Johannes Waldmann <johannes.waldm...@htwk-leipzig.de> writes: > Hi, > >> ... to compile it with a profiled GHC and look at the report? > > How hard is it to build hackage or stackage > with a profiled ghc? (Does it require ghc magic, or can I do it?) > Not terribly hard although it could be made smoother.
To start you'll need to compile a profiled GHC. To do this you simply want to something like the following, 1. install the necessary build dependencies [1] 2. get the sources [2] 3. configure the tree to produce a profiled compiler: a. cp mk/build.mk.sample mk/build.mk b. uncomment the line `BuildFlavour=prof` in mk/build.mk 4. `./boot && ./configure --prefix=$dest && make && make install` Then for a particular package, 1. get a working directory: `cabal unpack $pkg && cd $pkg-*` 2. `args="--with-ghc=$dest/bin/ghc --allow-newer=base,ghc-prim,template-haskell,..."` 3. install dependencies: `cabal install --only-dependencies $args .` 4. run the build, `cabal configure --ghc-options="-p -hc" $args && cabal build` You should end up with a .prof and .hp file. Honestly, I often skip the `cabal` step entirely and just use `ghc` to compile a module of interest directly. [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation [2] https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources >> ... some obvious sub-optimal algorithms in GHC. > > obvious to whom? you mean sub-optimality is already known, > or that it would become obvious once the reports are there? > I think "obvious" may have been a bit of a strong word here. There are sub-optimal algorithms in the compiler and they can be found with a bit of work. If you have a good testcase tickling such an algorithm finding the issue can be quite straightforward; if not then the process can be a bit trickier. However, GHC is just another Haskell program and performance issues are approached just like in any other project. > Even without profiling - does hackage collect timing information from > its automated builds? > Sadly it doesn't. But... > What needs to be done to add timing information in places like > https://hackage.haskell.org/package/obdd-0.6.1/reports/1 ? > I've discussed the possibility with Herbert to add instrumentation in his matrix builder [3] to collect this sort of information. As a general note, keep in mind that timings are quite unstable, dependent upon factors beyond our control at all levels of the stack. For this reason, I generally prefer to rely on allocations, not runtimes, while profiling. As always, don't hesitate to drop by #ghc if you run into trouble. Cheers, - Ben [3] http://matrix.hackage.haskell.org/packages
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs