> 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
