... | ... | @@ -48,7 +48,7 @@ Here are some tips and tricks: |
|
|
|
|
|
- When comparing the profiles of multiple versions of GHC, you may find yourself needing to maintain multiple build trees with different code. An extremely useful utility for this case is `git-new-workdir`, which is not a default Git command but lives in the `contrib` folder of Git. You can `locate git-new-workdir` to find your copy; it is most commonly installed to `/usr/share/doc/git/contrib/workdir` and add it to your path. Now you can use this command (`git-new-workdir old-working-copy new-working-copy`) to create a new working directory from the old Git repository, that has its own index but shares a repository with the original. Be sure to switch to a different branch, since branch pointers are shared too! What is especially convenient is if you make and commit a temporary change in one working-copy, you can immediately cherry-pick it from the other one, no fetching or patches necessary!
|
|
|
|
|
|
- One important thing to note is that by default, GHC does not define very many cost centers. So if you are comparing the results of two profiles, you may notice that everything gets attributed to something not very informative (e.g. `defaultCleanupHandler`). This is by design: if we slapped `-auto-all` on all of our source files, the profiles would be a lot harder to interpret because there would be so much noise. Instead, you should selectively apply `-auto-all`, probably to the files changed in the offending commit. [compiler/ghc.mk](/ghc/ghc/tree/master/ghc/compiler/ghc.mk) has some guidance on the matter: you can either set `compiler/main/GhcMake_HC_OPTS` to `-auto-all`, or you can add `{-# OPTIONS_GHC -auto-all #-}` to the top of the relevant files. The latter has the benefit that it will also properly trigger recompilation; however, if you're sharing your ``build.mk`` between the old and the new trees, adding the appropriate `HC_OPTS` to your build files prevents you from having to duplicate changes in both trees. These variables can also be passed to `make` on the command line.
|
|
|
- One important thing to note is that by default, GHC does not define very many cost centers. So if you are comparing the results of two profiles, you may notice that everything gets attributed to something not very informative (e.g. `defaultCleanupHandler`). This is by design: if we slapped `-auto-all` on all of our source files, the profiles would be a lot harder to interpret because there would be so much noise. Instead, you should selectively apply `-auto-all`, probably to the files changed in the offending commit. [compiler/ghc.mk](https://gitlab.haskell.org/ghc/ghc/tree/master/ghc/compiler/ghc.mk) has some guidance on the matter: you can either set `compiler/main/GhcMake_HC_OPTS` to `-auto-all`, or you can add `{-# OPTIONS_GHC -auto-all #-}` to the top of the relevant files. The latter has the benefit that it will also properly trigger recompilation; however, if you're sharing your ``build.mk`` between the old and the new trees, adding the appropriate `HC_OPTS` to your build files prevents you from having to duplicate changes in both trees. These variables can also be passed to `make` on the command line.
|
|
|
|
|
|
- Comparing time/allocation profiles from `-p` can be a bit of a pain, especially if you're tracking a minor regression. It would be nice if there was a tool for comparing profiles. #9419 tracks a feature request for adding a machine-parseable version of this output.
|
|
|
|
... | ... | @@ -61,7 +61,7 @@ Here are some tips and tricks: |
|
|
## Re-running Haddock perf benchmarks
|
|
|
|
|
|
|
|
|
One interesting idiosyncracy of GHC validate is how the Haddock performance tests (found in [testsuite/tests/perf/haddock](/ghc/ghc/tree/master/ghc/testsuite/tests/perf/haddock)) are setup. In particular, they do \*not\* actually go ahead and run Haddock; instead, they read out the file `base.haddock.t` (and variants) which gets written out with garbage collection statistics during the build process itself. How, then, might one go about re-running the tests? The answer is that the files themselves contain the command line which was used to make the invocation. Thus, one workflow might proceed as follows:
|
|
|
One interesting idiosyncracy of GHC validate is how the Haddock performance tests (found in [testsuite/tests/perf/haddock](https://gitlab.haskell.org/ghc/ghc/tree/master/ghc/testsuite/tests/perf/haddock)) are setup. In particular, they do \*not\* actually go ahead and run Haddock; instead, they read out the file `base.haddock.t` (and variants) which gets written out with garbage collection statistics during the build process itself. How, then, might one go about re-running the tests? The answer is that the files themselves contain the command line which was used to make the invocation. Thus, one workflow might proceed as follows:
|
|
|
|
|
|
1. Do a normal build of the GHC tree with `HADDOCK_DOCS = YES`
|
|
|
1. Look at `libraries/base/dist-install/doc/html/base/base.haddock.t`, which now contains a giant command line. Copy this line into a shell script file.
|
... | ... | |