Profile, then find the worst offending areas, and target them. Perhaps a better data structure, or a different algorithm would change the usage.

Update: Perhaps one of the Devel::Size type modules might help with this.

Some algorithms have more memory overhead but run faster. Others run more slowly, but take less memory.

A contract I am doing right now has frozen data in a database (basically a key/value setup with a frozen representation of a HoHoHoH... structure as the value), Some of the values are causing the application to run out of memory when being processed. By making each level of the hash another column and letting the database do much of the heavy lifting, I am saving memory, hopefully saving time (not needing to thaw the large data structure), and making a much more scalable application.

In summary, the algorithm and data structure can make a tremendous difference.

Se, I profiled it, and it runs nice and fast - but my issue is, it takes up a lot of memory, which with enough processes becomes swap, which becomes crash.

dprofpp doesn't say what memory it takes up - is there anything that does?

See, I've read both of those - one cover-to-cover (in dead-tree format) - but while they talk a lot about how to optimize mod_perl, there's nothing I've found that says 'type this to see how much memory your program will take up'.

Well, that should tell you something. :)

There is no way to predict it with any accuracy. I think the perlfaq spells this out pretty clearly too. What you have to do is run your program with your real data, see how big it is, and then make changes and repeat.

There are some common culprits for large programs, and I believe they are all described in those docs, as well as ways of measuring the size of a running program. There's way to measure the size of a non-running program. It is very data dependent.

So your program makes some SQL requests? Maybe returned dataset is too big? Test your SQL requests in standalone scripts and see how much memory they would use.