MashMashy has asked for the wisdom of the Perl Monks concerning the following question:

The end-result of what I'm looking for is to take the file test.pl and do something that will go "this will take up X bytes in memory", so I can hack at it, do that 'something' again, and have it say "this will take up Y bytes in memory", so I know if my optimization is having any effect.

I look at my 'top' output, but that ony gives memory allocation 'in progress' - I can't get a quantifiable look at two different programs, to see which takes less or more, and by how much.

Thanks for any help!
  • Comment on A way to see how much 'memory' a program will take up in, say, mod_perl, so I can start to optimize it?

Replies are listed 'Best First'.
Re: A way to see how much 'memory' a program will take up in, say, mod_perl, so I can start to optimize it?
by MidLifeXis (Monsignor) on Feb 19, 2009 at 18:42 UTC

    It sounds like you are asking to predict the memory that will be used by an application, right?

    Is the application data driven? In other words, the data passed into an application can cause the size used to grow tremendously. As a simple example...

    while (<>) { push(@lines, $_); }

    --MidLifeXis

      You know, you are absolutely right - it does read in from a SQL database, which makes this much more complicated..

      How would you suggest going about something like 'cutting down the amount of memory taken in mod_perl?'

        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.

        --MidLifeXis

        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.

Re: A way to see how much 'memory' a program will take up in, say, mod_perl, so I can start to optimize it?
by sflitman (Hermit) on Feb 20, 2009 at 02:50 UTC
    I may be missing something here, but couldn't you use the /proc filesystem? Read /proc/self/status or /proc/pid/status from a test harness and you can interrogate the line VmData and figure out how many pages it has used.

    Also, you may like perldebguts, you can get a lot of memory info if Perl was built with its own malloc.

    Also also, I remember from the way-back C days there was a call 'sbrk()' which told you in a relatively pan-system way where you were with memory allocation, it is how malloc works. In Perl you'd need an XS to get at it, but again CPAN may come to the rescue.

    HTH,
    SSF