[Win32] PAR-generated .exe consuming excessive CPU on initial load

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

Greetings,

I am using PAR-0.86 with ActivePerl 5.8.6 for Win32 to generate an executable from a script. My code totals about 500 lines, but I do use several modules. The generated EXE is about 3.3 MB in size. The program runs fine, but the first time I run it on a given machine, it seems to eat 100% CPU on that machine for about 30-40 seconds before it begins to do its real work. This is on a fairly recent desktop computer with a P4 and 512 MB RAM. I'm wondering if I could reduce it either with a configuration change, or by switching to one of the commercial Perl exe-generators such as PDK or Perl2Exe. Some of the modules I'm using, such as LWP, Tk, and XML::LibXML are pretty large. If I could eliminate one or more of them would that likely make a big difference?

Cheers

Comment on [Win32] PAR-generated .exe consuming excessive CPU on initial load

Replies are listed 'Best First'.
Re: [Win32] PAR-generated .exe consuming excessive CPU on initial load by jplindstrom (Monsignor) on Apr 26, 2005 at 20:41 UTC
The first time you run the binary, PAR will unzip the contents to a temp directory. This is probably the cause of the initial CPU load. A problem with all packagers (PAR, PerlApp, perl2exe) is their choise of modules to include. Either they miss modules which you need to manually include, or they find too many dependencies and bundle a huge portion of the modules you have installed. If you want to minimize the startup time you may want to try the -S option and look at exactly what's in the zip file (rename the file to .zip and unzip it with e.g. WinZip) and then use -X to exclude the modules. You could also try the -z option to try to turn off compression. The pp docs. /J	[reply]
Re: [Win32] PAR-generated .exe consuming excessive CPU on initial load by TGI (Parson) on Apr 26, 2005 at 20:51 UTC
What you are seeing is the PAR decompressing to a temporary directory. PAR leaves files in a specified temp directory to speed successive executions of the same package. I use PAR and PerlApp with great success. Each has its strong points. PerlApp has somewhat faster startup times and a smaller memory footprint. PAR generates smaller binaries and it is easy to look inside a package. Even if you use PerlApp you will still have some lag at startup and a short period where CPU utilization peaks while perlapp decodes its proprietary format. P.S. Here's an example of what I mean when I say perlapp starts up faster. I have a ptk app that makes a perlapp binary that weighs in at 3.8 MB. The equivalent PAR file is 2.8 MB on disk. In memory, perlapp takes 18.8 MB, PAR takes 22.3 MB. When I start both apps at the same time (second run for each) the PAR loads about 1.5 seconds after the perlapp file. YMMV TGI says moo	[reply]
Re: [Win32] PAR-generated .exe consuming excessive CPU on initial load by kimanaw (Beadle) on Apr 27, 2005 at 02:02 UTC
I've encountered similar difficulties (which ultimately led me back to perl2exe). My observations were that PAR tends to "run amok" when it resolves dependent modules, and pulls in a lot of extra stuff you probably don't need. In my case (a fairly large scale ptk app), the PAR archive file was >10Megs, while the perl2exe was about 6 megs. Initial bootup times for PAR were completely unacceptable; perl2exe is pretty reasonable (and it opens a ptk splash screen much quicker as well.) Even after the initial bootup, the PAR boot time was much greater than perl2exe. Another PAR downside (IMHO) is the reliance on the temp directory structure; once people suss out their temp directories, they've got to endure the long load again. PAR could mitigate some of this by providing a splash screen hook, but thus far that feature seems to be low priority. While I appreciate the PAR toolset (esp for supporting more exotic platforms), I'd recommend perl2exe if you're running on a mainstream platform (Win32, Linux, Solaris).	[reply]