my $size = `ps -p $$ -h -o size`;

This reports the size of the process in K.

On windows machines you can't go past the utilities by SysInternals, now part of MicroSoft. For memory usage most useful are Process Explorer and pstools

On *nix systems there is ps, pmap, vmstat and others. The man pages for them will have a SEE ALSO section that lists other related commands, some of them are platform specific. Most linux distribution include some sort of GUI system monitor such as SUSE's KSysGuard. Solaris and Max OSx have DTrace.

On systems for which libgtop is available, you could use GTop (or more specifically GTop::Mem). This excludes Windows, though, I think... (but I'm not entirely sure).

Update: Oops, didn't read your question carefully enough... (early in the morning!). Just ignore.

Try Devel::Peek and Devel::Size.
An excellent guide on how to use them is in brian_d_foy's Mastering Perl, pp 102-107.

These do not answer the OPs question. Devel::Size will report the size of (some) internal structures, but not the overall program.

Also, when using it to determine the size of large nested hash/array structures, it can use a substantial amount of memory internal to itself, in order to detect circular references, which can exacerbate problems rather than helping fix them.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Thank-you for all your helpful suggestions. It looks like Proc::ProcessTable will do what I want. And yes, that thread from 2001 has the answers I need. Cheers, mildside

And here is one using Gtk2 GMeM -- a Gtk2 memory monitor utility

Bear in mind that the memory-used amount can be overstated, depending on how you arrive at the figure. For instance, memory is allocated from the operating-system in chunks and those chunks may or may not be released back to it as often as you might think they should be. (Since the “memory” in question is virtual, it doesn't really matter too much anyhow.)

Perl uses a built-in “garbage collector” to manage its (virtual) storage, and for performance reasons it does not run that garbage-collector constantly. In all matters of computing, there is always a fundamental tradeoff of “speed vs. space,” and implementors will invariably choose “speed.”

On the operating-system level, there's the factor of “laziness.” The operating system (and this does depend on exactly what system it is...) generally won't bother to do something unless and until it is forced to. (Like any good college student, it'll let the garbage pile up until Mom's coming to visit...)

Therefore, a much better metric might be to consider the degree to which whatever your program is doing is actually, measurably, stressing the system. If there is actually a sustained swap-rate, with physical swap-I/O occurring on a regular basis, then the system is under some degree of stress. If your program is the cause of that stress, “this is not a good thing.” Similarly, if your program's memory-reference patterns are such that it gets unduly penalized when it finds itself running in an environment with a moderate amount of “ambient stress,” this is also not a good thing.

You can definitely tell when a package was developed on a fast development-machine with gobs of memory. Before releasing a substantial package out into the wild, you need to subject it to some stress-testing. (Unfortunately, fixing the problems that may surface in such testing can be quite expensive, so perform these tests early and continuously.)