cost of modules

[Fawzi Mohamed]

woops sorry for the previous post, the subject was wrong... this one is 
correct.

Simon Peyton-Jones wrote:
>  Generally speaking GHC will inline *across* modules just as much as
>  it does *within* modules, with a single large exception.
>
>  If GHC sees that a function 'f' is called just once, it inlines it
>  regardless of how big 'f' is.  But once 'f' is exported, GHC can
>  never see that it's called exactly once, even if that later turns out
>  to be the case.  This inline-once optimisation is pretty important
>  in practice.
>
>  So: do not export functions that are not used outside the module
>  (i.e. use an explicit export list, and keep it as small as possible).

This is very interesting to know, as it explains a strange effect that I
was seeing: I had an algorithm and I began to add variants of it as
separate functions in the same module.
Then I saw the original function (which I had not touched) get slower
and slower.
I even wondered if the compiler was not maybe taking common parts of my
functions out of them to reduce the evaluations making my original
function slower, but then it was that it wasn't inlining anymore some
functions.

This means the with haskell (with ghc) cleaning up old code and keeping
the modules as clean as possible pays off even more than in other
languages...
good to know, and very important when benchmarking various algorithms:
commenting out a variant is better as having it as separate function....

Fawzi