Haskell: unnecessary binary growth with module imports

后端 未结 1 1480
情深已故
情深已故 2020-12-30 13:06

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)


        
相关标签:
1条回答
  • 2020-12-30 13:44

    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.

    0 讨论(0)
提交回复
热议问题