Performance/Modules: Difference between revisions
m (+infobox) |
DuncanCoutts (talk | contribs) mNo edit summary |
||
| Line 2: | Line 2: | ||
== Use an explicit export list == | == Use an explicit export list == | ||
(note: this only applies to compilers based on separate compilation, not to those based on whole-program compilation like [[JHC]]). | (note: this only applies to compilers based on separate compilation like [[GHC]], not to those based on whole-program compilation like [[JHC]]). | ||
If you do not have an explicit export list in a module, the compiler must assume that everything in that module will be exported. This disables various useful optimisations: | If you do not have an explicit export list in a module, the compiler must assume that everything in that module will be exported. This disables various useful optimisations: | ||
Revision as of 11:22, 16 January 2006
| Haskell Performance Resource
Constructs: Techniques: |
Use an explicit export list
(note: this only applies to compilers based on separate compilation like GHC, not to those based on whole-program compilation like JHC).
If you do not have an explicit export list in a module, the compiler must assume that everything in that module will be exported. This disables various useful optimisations:
- If a function is used only once in the current module, and not exported, there is no penalty for inlining the function at its single use point.
- If a function is not used at all, and not exported, its definition can be discarded.
- The compiler has more flexibility regarding calling conventions and the like for functions that are not visible beyond the current compilation unit.