Hi! That's indeed a very nice thing to look into! (My application could do with a boost a start-up...)
Unfortunately I'm a bit short of time right now, and not skilled in anything useful for this, but I'll test it under Linux (nothing new, but my extra old OS might expose some things), SGI Irix (always causing some trouble!), Windows (...) and Solaris. I'll get back to you ASAP. Cheers! Philippe Steffen Mueller wrote: > > 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
