in reply to Re^15: problem with par as other user
in thread problem with par as other user
On the speed - after PAR cached its unZIP (after its first run), it will be very the same as within perl library itself, just with slightly different @INC path, it should be reasonably slow only first time. (this is all configurable, AFAIK)
But if you do want speed boost within perl/Tk apps - go to Tcl::Tk, its faster x2, in addition to be more flexible.
Yet perl's memory allocator is a win on win32.
Actually I agree on all your points about PAR and perl2exe (I meanHDD and opensource)
Moreover, I suspect that commercial packers go very same way as I did, but their added value is not very deep, its quite near on the surface...
they did more testing than I did and wrote code, but essential part is small. Perl is almost redistributable without additional packers.
An essential additional remark:
I did several versions of bootstrap mechanics of what you've just reviewed, WRT who unzips the file module/perl58.zip
In some versions its Perl's Archive::Zip, but in the version you've tried this is Tcl/Tk's unzipping.
If moving to CPAN, then Perl-only solution is preferred, but Tcl/Tk way was faster in this particular case
(usually perl faster than tcl/tk a bit, but extracting members from perl58.zip was faster in Tcl/Tk because it was implemented in C internally)
Sometimes I just scared on how many ways to do things. TIMTOWTDI.
Best regards,
Courage, the cowardly dog...
... err, Vadim.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^17: problem with par as other user
by Ace128 (Hermit) on Jun 30, 2006 at 21:21 UTC | |
by vkon (Curate) on Jul 01, 2006 at 08:05 UTC | |
by Ace128 (Hermit) on Jul 02, 2006 at 15:46 UTC | |
by vkon (Curate) on Jul 02, 2006 at 17:06 UTC |