Question

When i import a (big) module into a Main module in one of the following ways:

import Mymodule
import qualified Mymodule as M
import Mymodule (MyDatatype)

the compiled binary grows the same huge amount compared to when i don’t import that module. This happens regardless of whether i use anything inside that module or not in the Main module. Shouldn’t the compiler (i am using GHC on Debian Testing) only add into the binary what is needed to run it?

In my specific case i have a huge Map in Mymodule which i don’t use in the Main module. Selectively importing what i really need, did not change the growth of the compiled binary.

Answer 1

As far as GHC is concerned, import lists are only there for readability and avoiding name clashes; they don’t affect what’s linked in at all.

Also, even if you did only import a few functions from a library, they might still depend on the bulk of the library internally, so you shouldn’t necessarily expect to see a size decrease from only using some of an available interface in general.

By default, GHC links in entire libraries, rather than only the pieces you use; you could avoid this by building libraries with the -split-objs option to GHC (or put split-objs: True in your cabal-install configuration file (~/.cabal/config on Unix)), but it slows down compilation, and is seemingly not recommended by the GHC developers:

-split-objs

Tell the linker to split the single object file that would normally be generated into multiple object files, one per top-level Haskell function or type in the module. This only makes sense for libraries, where it means that executables linked against the library are smaller as they only link against the object files that they need. However, assembling all the sections separately is expensive, so this is slower than compiling normally. Additionally, the size of the library itself (the .a file) can be a factor of 2 to 2.5 larger. We use this feature for building GHC’s libraries.

— The GHC manual

This will omit unused parts of libraries you use, regardless of what you import.

You might also be interested in using shared Haskell libraries.