RE: how to determine a programs memory usage at runtime?

On 22 June 2004 03:51, Bernard James POPE wrote:
The mblocks_allocated variable should give me what I want.
I think having access to this would also be useful to people who are profiling their programs. You see a few papers where people want to report how much memory their application needs, and having a high-water mark is usually good enough. Beats trying to get the information from top.
Note that this only counts memory allocated by the GHC storage manager; it doesn't include the data segments, malloc(), the C stack, or other mmap()'d stuff. Be careful if your program is using any of these other allocation methods (perhaps via an external library through the FFI). Cheers, Simon

On Tue, Jun 22, 2004 at 09:27:40AM +0100, Simon Marlow wrote:
On 22 June 2004 03:51, Bernard James POPE wrote:
The mblocks_allocated variable should give me what I want.
I think having access to this would also be useful to people who are profiling their programs. You see a few papers where people want to report how much memory their application needs, and having a high-water mark is usually good enough. Beats trying to get the information from top.
Note that this only counts memory allocated by the GHC storage manager; it doesn't include the data segments, malloc(), the C stack, or other mmap()'d stuff. Be careful if your program is using any of these other allocation methods (perhaps via an external library through the FFI).
Ah, that's a good point. I didn't think of that. For what it is worth I've put a simple Haskell wrapper to mblocks_allocated on the web. It provides this function: megaBytesAllocated :: IO Integer On my simple tests it seems reliable, when compared to what top says. I've put it here in case anyone wants to use it: http://www.cs.mu.oz.au/~bjpop/code.html Cheers, Bernie.

On Tue, Jun 22, 2004 at 09:27:40AM +0100, Simon Marlow wrote:
On 22 June 2004 03:51, Bernard James POPE wrote:
The mblocks_allocated variable should give me what I want.
I think having access to this would also be useful to people who are profiling their programs. You see a few papers where people want to report how much memory their application needs, and having a high-water mark is usually good enough. Beats trying to get the information from top.
Note that this only counts memory allocated by the GHC storage manager; it doesn't include the data segments, malloc(), the C stack, or other mmap()'d stuff. Be careful if your program is using any of these other allocation methods (perhaps via an external library through the FFI).
Might it be worthwhile adding to the foreignPtr interface a way of telling the RTS how much memory that foreignPtr actually uses? It might be useable in an advisory sense in deciding which garbage to collect, or just in an informational sense (as here), when one wants to see how much memory is used (or, for example, when profiling). One could also add an extra "user" flag, so perhaps when profiling memory usage one could look at only "mmapped" memory usage, or something like that. The "user" flag could perhaps be ignored when compiling without profiling... -- David Roundy http://www.abridgegame.org
participants (3)
-
Bernard James POPE
-
David Roundy
-
Simon Marlow