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
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