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