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. 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 ? 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. 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/ ) > 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. But I've never used one, so I'm arguing from a position of ignorance. Nicholas Clark
