memory distribution in ghci

[S.D.Mechveliani]

To my request

> [..]
> can  ghci  provide a command measuring the part of heap taken
> by interpreted programs,
> by interfaces?
> (or, at least, their sum)

Simon Marlow  <simonmar@microsoft.com> writes


> Ah, I see now.  You'd like to know how much memory your program is
> using, compared to GHCi itself?  Hmm.  Unfortunately I can't see a good
> way to do this I'm afraid.  

In                            ghci ... +RTS -Mxxxm -RTS
xxx  sets the volum bound for  
                    (1) `real' data          +  
                    (2) interpreted program  + 
                    (3) interfaces of pre-compiled loaded .o modules.

Please, confirm, whether I understand correct?
And many users would like to measure (1) within the  ghci  loop.

The statistic like   Prelude> List.sort [1..10]
                     [1,2,3,4,5,6,7,8,9,10]
                     (0.53 secs, 7109100 bytes)

includes the number of allocations, which cannot help to detect (1)
(can it?)
This is a user's wish for the future  ghci  version.

I do not know, whether it is hard to develop.
If it is hard, personally, I would not suffer much.
Because, getting "heap exhausted", one can run  ghci  once more,
with larger  xxx,  and performing the same computation to detect
approximately which part of  xxx  is taken by the `real' data.
But this looks awkward.

Another wish: to document the  ghci  memory management
-------------
which we are discussing now.
Because GHC could simply give a reference to the manual section.


> However, you can always compile the program
> and use profiling...

Suppose User demonstrates an Haskell application A to the Listener. 
Naturally, most of  A  constitutes its `library'  L,  and  L  was 
compiled to .o files
                     (desirably, gathered in the  libL.a  archive).

ghci  invokes, loads the _interpreted_ demonstration code  D,
much smaller than  L,  but importing items from  L.
Naturally, Listener asks something like 
"and how much memory needs to compute this matrix?".

In many other system, the interactive command, say, `:size'
gives immediately some interpreter memory map and the sizes taken
by `code' and `data'.
And you suggest to wait 2 hours to re-compile _everything_ with 
profiling. The Listener would not wait.


>> For, with -O and much in-lining, the interfaces may be very large.

> You really don't want to use -O with GHCi (in fact, at the moment you
> can't).

This may be serious. For example,  putStr $ show (sum1 [1..n])

will need a constant memory or O(n) memory depending on the  -O
possibility.
The docs on ghc-5.00 say that it joins "the best of the two worlds" - 
interpreted code calling for the fast code compiled earlier. 

Generally, I like only scientifically designed `interpreters' and
always advised not to spend efforts to .o compilation.
But as nobody agrees with me, as the o-compilation fiesta continues, 
then, why to spend effort in vain?

-----------------
Serge Mechveliani
mechvel@botik.ru