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?
Yes, that's right.
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?)
No, it can't.
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.
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...
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.
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