graphql-engine/cabal
Antoine Leblanc a0a2492fe3 add -fsolve-constant-dicts to local environment
## Description

When working locally, we often run into [ghc#16932](https://gitlab.haskell.org/ghc/ghc/-/issues/16932): redundant constraints warnings do not fire, because optimizations are disabled, but they end up making the build fail on CI where optimizations are enabled. This PR enables `-fsolve-constant-dicts` in the local environment, which guarantees that this warning will always fire locally. This doesn't seem to have a measurable impact on compilation time or memory use, as far as i could tell.

PR-URL: https://github.com/hasura/graphql-engine-mono/pull/8305
GitOrigin-RevId: 0eac572464a3c6861be8b8c176ea9257f14e4226
2023-03-14 15:41:27 +00:00
..
ci-haddock.project server: Clean up Cabal project files 2022-04-07 07:16:12 +00:00
ci-haddock.project.freeze server: Clean up Cabal project files 2022-04-07 07:16:12 +00:00
ci-haddock.project.local Fix build errors related to dynamic building 2022-11-21 15:07:53 +00:00
ci.project server: Clean up Cabal project files 2022-04-07 07:16:12 +00:00
ci.project.freeze server: Clean up Cabal project files 2022-04-07 07:16:12 +00:00
ci.project.local server: fix cabal and warnings for arrows related packages 2023-02-02 19:53:13 +00:00
dev-sh-optimized.project server: dev build modes 2023-02-08 22:43:00 +00:00
dev-sh-optimized.project.freeze server: dev build modes 2023-02-08 22:43:00 +00:00
dev-sh-optimized.project.local server: dev build modes 2023-02-08 22:43:00 +00:00
dev-sh-prof-heap-infomap.project server: dev build modes 2023-02-08 22:43:00 +00:00
dev-sh-prof-heap-infomap.project.freeze server: dev build modes 2023-02-08 22:43:00 +00:00
dev-sh-prof-heap-infomap.project.local server: dev build modes 2023-02-08 22:43:00 +00:00
dev-sh-prof-ticky.project server: dev build modes 2023-02-08 22:43:00 +00:00
dev-sh-prof-ticky.project.freeze server: dev build modes 2023-02-08 22:43:00 +00:00
dev-sh-prof-ticky.project.local server: dev build modes 2023-02-08 22:43:00 +00:00
dev-sh-prof-time.project server: dev build modes 2023-02-08 22:43:00 +00:00
dev-sh-prof-time.project.freeze server: dev build modes 2023-02-08 22:43:00 +00:00
dev-sh-prof-time.project.local server: dev build modes 2023-02-08 22:43:00 +00:00
dev-sh.project server: Clean up Cabal project files 2022-04-07 07:16:12 +00:00
dev-sh.project.freeze server: Clean up Cabal project files 2022-04-07 07:16:12 +00:00
dev-sh.project.local add -fsolve-constant-dicts to local environment 2023-03-14 15:41:27 +00:00
dev.project server: GHC 9.2 changes compatible with 8.10 (#3550) 2022-06-25 22:09:05 +00:00
README.md server: dev build modes 2023-02-08 22:43:00 +00:00

At the top level we have a cabal.project file that defines project configuration settings that stay the same, regardless of whether we're doing local development, building on CI, etc.

Additionally in this directory we have various cabal.project.local files that add or override settings depending on context:

  • ci-*.project.local - these are used when building in CI (see .buildkite/)
  • dev-sh.project.local - this is used to configure the environment we expect in scripts/dev.sh, and is where we put good local development defaults
  • dev-sh-optimized.project.local - above, but building with optimizations, suitable for prod-like performance testing
  • dev-sh-prof-*.project.local - Various profiling modes (see below)

Because we can only gives us --project-file to select configuration, we need each of these local overrides to have a symlink back to the top-level cabal.project. So e.g. if you wanted to build with CI settings locally you would do:

$ cabal build --project-file=cabal/ci.project exe:graphql-engine

Likewise for the freeze file symlinks.

In cabal-install 3.8 we can have imports, which we also use.

Here's a helper for making new configurations:

function hasura_new_sub_config () {
    cd "$(git rev-parse --show-toplevel)/cabal"
    ln -s ../cabal.project.freeze "$1.project.freeze"
    ln -s ../cabal.project "$1.project"
    touch "$1.project.local"
    echo "continue editing: $1.project.local"
    cd - &>/dev/null
}

Profiling modes

See the graphql-engine --prof-* flags in dev.sh for the happy path to use these modes.

+RTS -hi(info map) Heap Profiles

Every distinct constructure allocation site is instrumented with source code information

See: dev-sh-prof-heap-infomap.project.local

  • Try it when: you want to go deeper debugging high resident memory during development
  • Benefits: doesn't inhibit optimizations, very granular
  • Downsides: must recompile, binary sizes can get large, sometimes source info is confusing

ghc-debug

A set of client and server libraries for snapshotting and arbitrarily analyzing the Haskell heap

  • Try it when: you need to answer any sort of complex question about what's in memory; e.g. why is something retained? do we have many identical strings and memory?
  • Benefits: extremely powerful, can run on production without restart
  • Downsides: analysis passes can take time to write and debug, analyzing large heaps requires care

“Ticky ticky” profiling

Generates a report for all allocations even those that are very short-lived; quasi- time profiling

See: dev-sh-prof-ticky.project.local

  • Try it when: debugging a regression and bytes allocated, comparing two different versions of code
  • Benefits: see and compare allocations directly, doesn't inhibit optimizations
  • Downsides: STG can take time to decipher, the program gets very slow, not suitable for production

-fprof-late time profiling

NOT YET IMPLEMENTED

Time profiling that instruments code after all significant optimizations have been performed, so it doesn't distort the profile (on 9.4+ only, but plug-in available)

See: dev-sh-prof-time.project.local

  • Try it when: you want to try to make some code faster, or understand where the time is being spent in the system
  • Benefits: get call stacks, granular view of execution time
  • Downsides: requires recompilation, STG can be confusing, not suitable for production