Hi Roderich,
sorry for the late reply, and thanks to the words of wisdom. As a lazy
engineer, I don't like duplicating code :-).
Anyhow, as my primitive benchmarks suggest that it's better to spawn off n
[default: 8] processes of 27 MByte than forking 75+ MByte ones,
it would be great to get my patch into POE::Component::Resolver.
I will provide a PoCo::Generic patch once I stumble across the problem
[currently not in use ... yet].
Cheers,
Markus
-----Original Message-----
From: Roderich Schupp [mailto:roderich.sch...@googlemail.com]
Sent: Sunday, May 22, 2011 3:55 PM
To: Markus Jansen
Cc: Steffen Mueller; poe@perl.org; p...@perl.org
Subject: Re: POE::Component::Resolver patch for PAR compatibility
On Thu, May 19, 2011 at 10:54 PM, Markus Jansen <markus.jan...@ericsson.com>
wrote:
> an "easier way" could mean some means to minimize the startup costs
> for the other Perl scripts - as --reuse targets toward the execution
> of external Perl scripts, we are talking here about "internal"
> scripts,
I can't see the difference between "internal" scripts (i.e. packed into the
executable) and "external" scripts here. The main cost is in both cases:
- executing the bootstrap program, i.e. the executable generated by pp (which
notices that the bootstrap stuff is already extracted)
- executing the already unpacked special purpose perl interpreter
- require'ing PAR::Packer and dependent modules
- finally running your script (whether it's below $ENV{PAR_TEMP} or somewhere
else)
The only way to save here is getting rid of the first exec (the unpacked
special purpose perl interpreter is actually $ENV{PAR_TEMP}/{basename of pp
generated executable}).
But that would mean to duplicate the setup (mostly environment stuff and
argument
preprocessing) currently done by boot.
Cheers, Roderich
