Hi [email protected], I have been experimenting with various ways to speed up the startup of large executables generated with PAR::Packer.
What it all comes down to is: Extracting the data with Archive::Zip is painfully slow. There are various ways to replace Archive::Zip in this context: - rely on external programs such as unzip - rely in different perl modules such as IO::Uncompress::Unzip - include your own unzip As a rule of thumb, IO::Uncompress::Unzip based code will be a couple of times faster than Archive::Zip and unzip is still up to a couple of times faster than IO::Uncompress::Unzip. I was going down the route of using IO::Uncompress::*, but the code I had was using the local ZIP file headers and not the central directory. This might have caused permission issues with the extracted code. The final blow to this approach (at least without doing a lot of work) was that it would fail to extract from a file which isn't purely a ZIP file such as the pp'd binary. That suite of modules is still rather young and quite promising, but at the moment, these two issues block me for using them. Finally, I have been experimenting with embedding a full unzip (well, InfoZip) into a Perl module and using that to burst all pp'd files to disk. I called my attempts Archive::Unzip::Burst. It's cheesy, I know. :) Anyhow. I checked a prototype into the PAR SVN repository at http://svn.openfoundry.org/par/Archive-Unzip-Burst and modified the PAR.pm and PAR::Packer's par.pl to use that module if it is available. A simple minded test had the full run time of a big pp'd binary go down from over eight seconds to about 1-1.5 seconds on my machine. There is some significant startup penalty from other parts of the process, so it won't go much lower than that. The problems with this approach can't be ignored, though: a) I'm not entirely sure what I did conforms to the license of InfoZip. I think so, since I left it basically untouched, but I'm not a lawyer. Thus, the module isn't on CPAN yet. b) I'd love to be able to strip some baggage from the distribution. Rolled as a .tar.gz it's >1MB now. The library adds ~200k to the pp'd exe. Again, I'm not sure this would be okay with InfoZip. I should talk to them, I suppose. Also, modifying the sources means blocking the upgrade path. c) unzip is portable, but my Makefile(.PL) hackery isn't. It would probably take someone who is better at XS (or Makefiles) to do this right. Additionally, I could only test the module on linux (32 and 64bit). *I really need somebody to fix it up on win32 and/or MacOS!* Right now, the optimization applies only to the special case of pp'd binaries bootstrapping themselves. Using PAR for accessing .par's is much harder to move away from Archive::Zip. It would take some form of optional "yes, I want this all to be extracted right now" switch to do that. I implemented the change so that if you don't have that module, things should work as usual. But if you do have it during packaging, it's used by default. Any comments? Testers? I'm pretty sure the new unzip module doesn't work on anything but linux out of the box. Cheers, Steffen
