memory distribution in ghci

[Simon Marlow]

> > Ah, I see now.  You'd like to know how much memory your program is
> > using, compared to GHCi itself?  Hmm.  Unfortunately I=20
> can't see a good
> > way to do this I'm afraid. =20
>=20
> In                            ghci ... +RTS -Mxxxm -RTS
> xxx  sets the volum bound for =20
>                     (1) `real' data          + =20
>                     (2) interpreted program  +=20
>                     (3) interfaces of pre-compiled loaded .o modules.
>=20
> Please, confirm, whether I understand correct?

Yes, that's right.

> And many users would like to measure (1) within the  ghci  loop.
>=20
> The statistic like   Prelude> List.sort [1..10]
>                      [1,2,3,4,5,6,7,8,9,10]
>                      (0.53 secs, 7109100 bytes)
>=20
> includes the number of allocations, which cannot help to detect (1)
> (can it?)

No, it can't.

> This is a user's wish for the future  ghci  version.
>=20
> I do not know, whether it is hard to develop.
> If it is hard, personally, I would not suffer much.

It's hard, because the three kinds of data you mention above can't
easily be separated.  It's entirely possible, due to the fact that GHCi
is sharing the heap with the running interpreted program, that the data
in use by the program could end up pointing to compiler data structures
(perhaps because parts of the code are lazilly compiled).

Furthermore, having an indication of the memory residency of the
interpreted program isn't much of an indication of the residency of a
compiled program, which is after all what really matters.  If you want
speed or memory efficiency, just compile the program.

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

I'll elaborate in the GHCi documentation.

> > However, you can always compile the program
> > and use profiling...
>=20
> Suppose User demonstrates an Haskell application A to the Listener.=20
> Naturally, most of  A  constitutes its `library'  L,  and  L  was=20
> compiled to .o files
>                      (desirably, gathered in the  libL.a  archive).
>=20
> ghci  invokes, loads the _interpreted_ demonstration code  D,
> much smaller than  L,  but importing items from  L.
> Naturally, Listener asks something like=20
> "and how much memory needs to compute this matrix?".
>=20
> 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=20
> profiling. The Listener would not wait.
>=20
> >> For, with -O and much in-lining, the interfaces may be very large.
>=20
> > You really don't want to use -O with GHCi (in fact, at the=20
> moment you
> > can't).
>=20
> This may be serious. For example,  putStr $ show (sum1 [1..n])
>=20
> will need a constant memory or O(n) memory depending on the  -O
> possibility.

True.  But compiling with optimsation takes 2-3 times longer than
interpreting - if you're prepared to wait that long, you might as well
compile instead.  Compiling will give more of a performance boost in
general (about 10x) than turning on -O (perhaps 2x).

Cheers,
	Simon