Dead code and compiled file size in Windows
Sorry for the free text format of the ticket now, but in this case I'll try to provide sample data if the discussion leads to it instead of upfront.
When I've switched from GHC 8 to GHC 9 for Windows, I've noticed that my .exe files grew a lot bigger.
At first I thought it had to do with the split-sections problem shown here: #22834 (closed) - but that is now fixed and I'm using GHC 9.6.3, with split-sections again.
Right now, if I make a small sample file that just outputs a string to the console but also uses my own custom prelude, my .exe file is ~ 13MB.
If I import my linear algebra module (a .hs file with more dependencies) but don't use anything from it at all, the file size grows to ~ 21MB.
I'm compiling as prod/optimized with these settings (Can't use the nonmoving GC via the RTS-opts right now because of #24042 (closed) - that should come with GHC 9.6.4 again):
@call ghc.exe -Weverything -Wmissing-signatures -Wno-missed-specialisations -Wno-all-missed-specialisations -Wno-implicit-prelude -Wno-missing-deriving-strategies -Wno-missing-fields -Wno-missing-home-modules -Wno-missing-import-lists -Wno-missing-local-signatures -Wno-monomorphism-restriction -Wno-name-shadowing -Wno-orphans -Wno-partial-fields -Wno-safe -Wno-tabs -Wno-unsafe -Wno-prepositive-qualified-module -Wno-missing-safe-haskell-mode -Wno-compat-unqualified-imports -Wno-operator-whitespace -Wno-missing-kind-signatures -XNoImplicitPrelude -I"D:\Projects\Haskell\final\..\headers" -threaded -fno-gen-manifest -optc-ffast-math -optc-fno-ident -split-sections -DWINVER=0x0602 -D_WIN32_WINNT=0x0602 -XBangPatterns -XCApiFFI -XConstrainedClassMethods -XConstraintKinds -XDisambiguateRecordFields -XDuplicateRecordFields -XEmptyCase -XEmptyDataDeriving -XExistentialQuantification -XExplicitForAll -XExplicitNamespaces -XFlexibleContexts -XFlexibleInstances -XForeignFunctionInterface -XFunctionalDependencies -XGADTs -XGADTSyntax -XGeneralizedNewtypeDeriving -XKindSignatures -XLiberalTypeSynonyms -XMagicHash -XMonoLocalBinds -XMultiParamTypeClasses -XNamedFieldPuns -XParallelListComp -XQuantifiedConstraints -XRankNTypes -XScopedTypeVariables -XStandaloneDeriving -XTypeFamilies -XTypeFamilyDependencies -XTypeOperators -XTypeSynonymInstances -XUnboxedSums -XUnboxedTuples -XNoFieldSelectors -O2 -tmpdir "D:\Projects\Haskell\final\..\_temp\ghc-r-temp" -odir "D:\Projects\Haskell\final\..\_temp\ghc-r-o" -hidir "D:\Projects\Haskell\final\..\_temp\ghc-r-hi" "D:\Projects\Haskell\final\t.hs" "t.res.o"
Before moving on, I'd like to clear up something:
Isn't GHC supposed to remove dead code that it can even warn me about (redundant import)?
Then, after the module level, I'd expect it to detect unused functions, constructs, etc. and remove those too in the intermediate representation before advancing further in the compilation process. In my intuition, Haskell should excel at this kind of flow graph analysis. And if it fails there, split-sections should be able to catch that and make up for it later. (I use this after the compilation: strip --strip-unneeded --strip-all --remove-section=.comment --remove-section=.note
)
I'm using export lists in my modules, but not import lists for the files that use them because they're too finicky in my programming.
I understand that .exe file size is really a secondary concern with the availability of resources and so on, and support for Windows is a little tricky in the Haskell ecosystem. But at this point it punishes me for having comprehensive code libraries of which I'm using different parts of for different projects, and because my main program more than doubled in size when switching from GHC 8 to 9 (now at ~36MB), I'm concerned.
Have I set up my compilation wrong somehow? I can imagine it has something to do with imported instances (haven't checked that yet), but none of them would be used in my small sample case.
Best regards. :)