I'm not familiar with PerlApp, so I am not aware of any guideline to minimize memory usage. But it sounds quite reasonable that the size of the executable is due to the modules you're using.

What I wanted to add is that strict (and warnings) per se has nothing to do with memory usage, AFAIK. But since you're already "forced" to use lexical variables, if you scope them suitably, then you should not need to explicitly "set them to undef when you don't need them anymore".

I'm trying to figure out exactly what Windows you're targetting where 2MB of disk space or 16MB of RAM is significant.

By its nature, perl uses more memory for the same work than, say, C. This is to allow the dynamic use where strings and numbers end up being the same thing as references, tied variables, etc. Each variable will have certain overhead to allow this. It's not the end of the world.

Then you use a bunch of Win32 modules - these will load additional Win32 DLLs into your perl programspace. But they aren't actually using additional memory - that same memory is being mapped into every process that uses those DLLs. And that would include the program that runs as your desktop.

Personally, I only care about memory when AIX tells me I've run out. And then I just tell AIX to shut up by resetting my ulimit ;-)

I'm using perlapp (and even more perlsvc) from AS PDK all the time at work.

A simple "Hello world!" (standalone program) will compile to short under 800K, since the exe will contain the perl interpreter in the form of the perl58.dll.

You can add (use) alot of pure perl modules in your program and the size of the resulting exe will not increase a lot (of about the size of the pm(s) these modules consist of).

The real problem arises when you include (a lot) of modules using compiled C code, i.e. attaching a module dll to your app.

You will quite easily break the 2MB with those (modules of the Win32 namespace are likely candidates to add most of the volume to your exe.)

This is something like needing the runtime module for Visual Basic programs. If you make your .exe program fully self-contained, it will run on computers that don't have Perl installed, and won't require addional .dll's. The problem is that the self-contained .exe must have all this functionality in it, which makes it large.

It is possible to select options in perlapp that will create much smaller .exe binaries. You can do this, if you know your .exe is going to be run on machines that have Perl installed, and that have perl*.dll. When using perlapp, click on the "Size" tab and check the boxes for "Make dependent executable", and "Exclude perl58.dll from executable".

If you're running several .exe programs, it may pay to have Perl and the .dll installed, and creating smaller .exe files that can use them. If it's only one or two programs, or if you don't have the option of installing Perl, then you are pretty well stuck with a large .exe and the memory use.