RE: POE::Component::Resolver patch for PAR compatibility

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:[email protected]] 
Sent: Sunday, May 22, 2011 3:55 PM
To: Markus Jansen
Cc: Steffen Mueller; [email protected]; [email protected]
Subject: Re: POE::Component::Resolver patch for PAR compatibility

On Thu, May 19, 2011 at 10:54 PM, Markus Jansen <[email protected]> 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