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

I'm writing a web application that is going to be run under modperl.
The application currently uses a number of large modules which for better or worse ( ok I admit it it's probably worse ) I have to keep using.

I would like to be able to load these modules up,call the functions and unload them so as to keep the memory footprint of application down.

Something along the lines of :
require Date::Manip;
$output = Date::Manip::ParseDate($input);
unrequire Date::Manip;
would be great.
Does anyone have any clue how this might be done or even if it us possible.

Replies are listed 'Best First'.
Re: Unloading a perl module
by Arguile (Hermit) on Nov 14, 2001 at 15:24 UTC
    Better to declare them in httpd.conf or a startup.pl type script.
    # httpd.conf PerlModule Date::Manip # or startup.pl use Date::Manip ();

    This allows them to be cached on server boot and shared between child processes. The () after the module in startup.pl is very important as it means the module won't polute your global namespace (exports nothing).

    This gives you the performance advantage of having the module already compiled and cached, while keeping your memory requirements (per child) down. Make sure to still use the module in your hanlder/script though; while not always nesseccary it gets pretty confusing if you don't.

    If you're running Apache::Registry or PerlRun the rules are slightly different. Check the guide for more info.

      Hi,
      After a quick supersearch, I came up with this node
      ---------------------------
      Dr. Mark Ceulemans
      Senior Consultant
      IT Masters, Belgium

      I've tested this in the past. I found that even if you don't have a startup.pl and just let your cgi scripts use the modules, they still get loaded into global namespace to be shared by all the children. I didn't do a lot of testing in this area, so your results may vary. If they do, I'd love to hear more about it.

        The manual states (IIRC) that modules are shared until you modify internal variables, and then they become specific to the process that modified the variable. So as long as you don't keep state in the modules (few do) you will be getting the most efficient treatment.

        ____________________
        Jeremy
        I didn't believe in evil until I dated it.

        This is only true if your CGI scripts get loaded during startup, i.e. any modules you load and any modules they load during server startup will be shared via copy-on-write.