There are several threads here on how to use a module conditionally and the consequences of the different ways to do that. Check out the replies to Checking to see if a particular Module is installed and error message if module doesn't exist? (the latter one doesn't go into as much detail but does have some new ideas not mentioned in the first thread).

You can certainly reduce memory use by not loading modules that you will not be using. Also, if you have a very big module that you only use a few routines of, then you might want to patch the module to use autoloading so that start-up time and memory consumption are reduced.

Yes, you can "unuse" a module but that won't return the memory to the operating system on most operating systems, including Win32 (it makes the memory available for Perl to reuse for other things, though). Note that pages of memory that aren't actively being used will only consume swap space, not real memory, so you might just want to add more swap space if you are running low on that.

Is it a good practice to do this: ?

if (Option{blah} enabled) {
    use Win32::Blah;
}
[download]

No. Because it has no effect at all. use statements are all executed at compile time so it is impossible to use modules conditionally.

You can, however, use require to do something very similar.

"Perl makes the fun jobs fun
and the boring jobs bearable" - me

In July, I completed the successful implementation of a modified version of Slash 0.3 on the Windows NT platform. If you know anything about the Slashcode project, one of the key components of the application architecture is a daemon named slashd. Slashd is the program in which most of the automated site housekeeping functions take place.

The first attempt at porting slashd to NT involved configuring the Perl script to start when the system booted. Right away, this was a problem because services that the daemon depended on (most significantly, the database) had not fully started by the time slashd began running. The script also had a nasty habit of dying under Windows for no apparent reason.

My next thought was that I should rewrite slashd as an NT / Windows 2000 service. This was before I began to depend upon PerlMonks, so I was lucky to have found the Dave Roth book that discusses writing services in Perl. When I started reading about what was involved in converting a daemon like slashd, and thinking through implications like memory use, I decided to explore other options.

What I ended up doing was modifying slashd so that it was a batch script that executed quickly. Then, I paid for a software product from Camellia Software called Batch Job Server. The product is referred to in Aeleen Frisch's book on Windows NT System Administration from O'Reilly.

As I say in this article on my Web Site, I am very satisfied with the performance of Batch Job Server in this sort of application. It was the best way to get slashd running on NT, from my perspective, because it minimized the number of code changes that would be necessary. More important to your question, however, is the fact that the memory associated with slashd was returned to the Operating System regularly. And, since Batch Job Server itself is a service, I have given up little of the reliability of execution that is the purpose of writing so much code in Windows as services in the first place.

I'm not sure this will be an option for you, but it should be pointed out as an alternative, particularly for those applications where the Windows service has not already been written.

Dave Aiello
Chatham Township Data Corporation