Modules and memory use

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

Replies are listed 'Best First'.
(tye)Re: Modules and memory use by tye (Sage) on Jan 19, 2001 at 22:26 UTC
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. - tye (but my friends call me "Tye")	[reply]
Re: Modules and memory use by davorg (Chancellor) on Jan 19, 2001 at 22:06 UTC
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. -- <http://www.dave.org.uk> "Perl makes the fun jobs fun and the boring jobs bearable" - me	[reply] [d/l]
Re: Modules and memory use by dave_aiello (Pilgrim) on Jan 20, 2001 at 11:18 UTC
Would you mind if I offer a completely different way of potentially solving the problem? 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	[reply]
Re: Modules and memory use by repson (Chaplain) on Jan 20, 2001 at 13:56 UTC
One possible way to return memory to the system is starting a new process, using exec or Win32::Process. This is only valid if your program will be sleeping for long periods of time (at least maybe 5 minutes or more). This way you can upon finishing running, start a new process from the same executable, with a clean memory usage which will not expand until you require the desired modules. Make sure you do use require and not use so they won't be loaded at compile time. This probably isn't what you are looking for, but I thought I'd mention it anyway.	[reply]


Perl-Sensitive Sunglasses
	PerlMonks