Hi again, I've been digging around in PAR and I've discovered that the slowdowns are caused by PAR::Heavy when it extracts these massive DLLs. There seems to be a buffered write (line: print $fh scalar member->contents) in _dl_extract that is the point of slowdown. This line passes a huge 3mb scalar around the stack and then writes it with print. All of that is very slow.
I've found that it's much faster to just use this instead of the print statement: $member->extractToFileHandle($fh); I haven't been able to speed up anything else, but my exe now starts on first run in around five seconds, and on subsequent runs it'll start in two seconds. This is much more reasonable for me. One thing I'd like to see in PAR is the ability to set the compression level used by Archive::Zip in the compressing process. This would affect the time it takes to decompress the PAR archive and would be valuable for different distribution environments (would allow those who don't care about size but need fast extraction to specify no compression (level 0), and those who care deeply about size but don't care about extraction times to specify high compression (level 9)). I'll poke around some more in PAR and try to find some other tweaks if possible. Best regards, Steve Pick > -----Original Message----- > From: Stephen Pick [mailto:[EMAIL PROTECTED] > Sent: 22 July 2004 13:06 > To: Alan Stewart; [EMAIL PROTECTED] > Subject: RE: PAR under Win32 startup times > > > > On 21 Jul 2004 at 15:17, Stephen Pick wrote: > > > > > Hi, > > > > > > I'm using PAR 0.85, and I'm wondering what on earth PAR is > > doing on the first-time execution of a stand-alone executable > > built with it. I use the following command to build my exe: > > > pp -vv -M utf8 --gui -o app.exe app.pl > > > > > > The packing process is reasonably quick, but on the first > > execution I have to wait up to twenty seconds for my > > application to actually start. I know that PAR is extracting > > the modules required to run the script to a temporary > > directory on the first run, but it surely should not take > this long. > > WinRAR can extract a .par archive built from the same script > > (including base modules) in under a second. > > > > How does the first time startup compare to the speed if you > > "set PAR_GLOBAL_CLEAN=1" > > before running the app, so it's not cached? > > When PAR_GLOBAL_CLEAN is set to 1, the start up time is always as slow > as the first run (i.e. very slow). When PAR_GLOBAL_CLEAN is > not set, the > start up time is very slow for the first run but on subsequent runs it > is acceptably speedy. > > I've noticed now that the problem appears to be the unpacking speed of > the Wx DLLs. wx.dll is 1,500kb and wxmsw242u.dll is 3,270kb. It takes > PAR ages to extract these two. I can see their filesize > increasing if I > keep hitting F5 when viewing the PAR cache directory. > > As I said, WinRAR/WinZIP/PkZIP extract a PAR file built with the > following command: > pp -B -p out.par app.pl > In less than one second. > > I should also point out that PAR seems to put the Wx dlls in cache > directory, but ALSO in the %cache%\inc\lib\auto\Wx directory. So it's > extracting two copies of these files. The ones placed in > %cache%\inc\lib\auto\Wx extract extremely fast (as expected) but the > same DLLs extract terribly slowly when PAR is placing them in > the cache > root directory (something it seems to do after extracting the > inc\lib\* > tree). > > Could it be that PAR is not freeing resources that it has used to > extract all the other files? It does seem to use a lot of RAM during > extraction, and if it's having to reserve more and more > memory then this > kind of slowdown would be expected (especially if Perl is involved in > that memory reservation). > > I did see the other thread about this, by the way, but it seemed to > avoid finding a reason for it and instead talked about splash screens > and reducing the amount of modules PAR bundles. I don't see > that either > of these things are the best solution to this problem. > > Best regards, > Steve Pick > >
