On Sat, Mar 01, 2003 at 05:13:38PM +0000, Nicholas Clark wrote: > On Sat, Mar 01, 2003 at 11:17:37PM +0800, Autrijus Tang wrote: > > NOTES > > Since version 0.60, all files and data are extracted into a temporary > > directory, with the same name as its CRC32 checksum, to speed up the > > loading time of the next round. To inhibit this behaviour, set the > > "PAR_CLEARTEMP" environment to a true value. > > Is it really faster to store temporary files? Maybe when I was playing with > reading @INC from zip files I had the speed advantage of all my > uncompression and housekeeping being in pure C.
On Unix I notice very small difference between cleartemp and not. But this request is by someone who noted, on Win2k an especially Win9x, opening many files for writing is expensive, and cachetemp reduces the loading time to 25% of cleartemp. > For a PAR that already includes an .so (and hence is platform specific) is > there any disadvantage (apart from complexity) in shipping decompression/ > housekeeping code as another .so ? Mostly complexity, and also sounds like premature optimization. We do not currently spend many cycles in PAR.pm itself, I think. > I presume zip files can be tacked onto the end of .so files, but I can't > see any (good) trick to transparently a perl script that happens also to > be an .so. True. > Hmm. Apart from .so file, script, zip and using -x to find the script bit. > (but you would need to parse the .so to ensure it contained no lines > matching /#!.*perl/ ) This sounds very cool but I'm not sure what you wish to accomplish by it. > > Namely: which behaviour should be the default? Should there be a knob in > > 'pp' [instead of/ in addition to] the environment environment to control > > the binary's tempfile-extracting behaviour? > > I think that it would be good to have a setting in the par file as to which > behaviour to use, which in turn can be overridden by the environment. > On the assumption that most people running things from par files won't have > the knowledge to know how to override things, so most of the time par files > will be run the way the creator thought best. This sounds like a very sane proposal. So setting PAR_CLEARTEMP to '0' will inhibit temp-creation behaviour even if the author intended it. I wonders which one should be the 'default', though... Thanks, /Autrijus/
pgp00000.pgp
Description: PGP signature
