> Steffen Mueller wrote: > That's actually a good idea: Avoiding dll file name clashes using a > directory for each external (non-perl-module) dll. Currently, we extract > the external dlls under their original name, IIRC. However, I don't know > how you can make those directories accessible to the dll loader without > appending *each* directory to $PATH. Doing that in a long path ($TEMP is > long on Windows, isn't it?) might quickly result in hitting the length > limitations of env. vars on Windows.
Long paths might be an issue, although if we're talking just a handful of libraries, in practice it might work just fine. > This seems *very* slow for infozip. Perhaps it's because of the hardware > (old hard disk?) or the filesystem, or because you have a really huge > binary. But infozip was blazingly fast in extracting even zips of tens > of megabytes of tiny files on my reasonably fast (2005) linux machine > using ext3. My test case is only 4MB. On Linux, the equivalent operation is only taking 0.2 s. This seems to be primarily a Windows issue. The machine I was testing on seems particularly slow. I tried on a different machine and see numbers like 1.55s for a full unpack and 0.157s for .dll only. This is still a 10x difference, but the absolute numbers aren't quite as interesting. It seems like Windows is very bad at creating lots of small files, so reducing the number of file creates is more important than the amount of data that is unpacked. > That is certainly the most elegant way to speed up PAR startup. It's one > of the longest standing criticisms that we don't do it that way. > Nicholas Clark's ex::lib::zip does this loading from memory using XS, if > I remember correctly. I don't remember whether or how it deals with > shared object files. It probably does. I took a quick look and I don't see anything that is explicitly dealing with object files. It's also based on the gzip library rather than zlib so it's not a drop in replacement. > Perhaps we should create a branch of PAR::Packer for these changes, > which will eventually lead to PAR::Packer >= 2.0. I've created a 'fastio' branch for par and PAR-Packer. --Scott
