"Setting up GHC" slowdown when going from GHC 9.0 to 9.4 about clash-compiler HOT 9 OPEN

Perhaps same as #2684 ?

from clash-compiler.

And maybe the same as martijnbastiaan/doctest-parallel#78..

from clash-compiler.

Is the executable dynamically linked?

from clash-compiler.

@gergoerdi This is the same issue as doctest-parallel runs into. Downgrading to GHC 9.4.7 / LTS 21.21 "fixes" the issue.

from clash-compiler.

Is the executable dynamically linked?

Stupid question but -- how do I tell?

from clash-compiler.

Stupid question but -- how do I tell?

OK so with stack build --cabal-verbose --verbose I was able to find the setup program generated by Cabal, which is what is running Clash in-proc (using Clash.Main.defaultMainWithAction) and indeed it is dynamically linked. I have no idea how to control this, since this program is built by Cabal/Stack from Setup.hs.

from clash-compiler.

@gergoerdi This is the same issue as doctest-parallel runs into. Downgrading to GHC 9.4.7 / LTS 21.21 "fixes" the issue.

FWIW I can confirm this.

from clash-compiler.

Stupid question but -- how do I tell?

OK so with stack build --cabal-verbose --verbose I was able to find the setup program generated by Cabal, which is what is running Clash in-proc (using Clash.Main.defaultMainWithAction) and indeed it is dynamically linked. I have no idea how to control this, since this program is built by Cabal/Stack from Setup.hs.

According to more stack build --cabal-verbose --verbose, the setup program gets compiled with the following flags:

ghc-9.4.8
        --make
        -odir /home/cactus/prog/clash/pong/.stack-work/dist/x86_64-linux/ghc-9.4.8/setup
        -hidir /home/cactus/prog/clash/pong/.stack-work/dist/x86_64-linux/ghc-9.4.8/setup
        -i -i.
        -clear-package-db -global-package-db -package-db=/home/cactus/sdk/stack/snapshots/x86_64-linux/27724336f5cab67ecb9719f752c3eaa6ba6a8ae2f840f16180637123d005e264/9.4.8/pkgdb -package-db=/home/cactus/prog/clash/pong/.stack-work/install/x86_64-linux/27724336f5cab67ecb9719f752c3eaa6ba6a8ae2f840f16180637123d005e264/9.4.8/pkgdb
        -hide-all-packages -package-id=Cabal-3.8.1.0 -package-id=base-4.17.2.1 -package-id=clashilator-0.1.3-IfbBYrcr43e6EtNP5GgB1K
        -optP-include -optP/home/cactus/prog/clash/pong/.stack-work/dist/x86_64-linux/ghc-9.4.8/setup/setup_macros.h
        /home/cactus/prog/clash/pong/Setup.hs
        /home/cactus/sdk/stack/setup-exe-src/setup-shim-6HauvNHV.hs
        -main-is StackSetupShim.mainOverride
        -o /home/cactus/prog/clash/pong/.stack-work/dist/x86_64-linux/ghc-9.4.8/setup/setup
        -threaded

Nothing immediately jumps at me that would set -dynamic.

from clash-compiler.

I was only asking whether the executable was dynamically linked, because I know that the clash binaries have a very slow startup time when they are statically linked (on non-Windows platforms) to Haskell libraries. So if you're saying that your binary is dynamically linked to other Haskell libraries, than that is not the issue.

I think you confirmed that the issue doesn't show itself with GHC 9.4.7, which suggests it's the same issue that was hurting doctest-parallel: https://gitlab.haskell.org/ghc/ghc/-/issues/23464

from clash-compiler.