Re: Persistent Perl
On Tue, Jun 12, 2001 at 09:54:01PM +0100, Robin Szemeti wrote: > is this anything like wot FastCGI does .. or is that summat different? Since 'this' is a bit muddy I couldn't say, though I do know that FastCGI works as a constantly running coprocess, so maybe -- Richard Clamp <[EMAIL PROTECTED]>
Re: Persistent Perl
On Tue, 12 Jun 2001, Simon Wistow wrote: > Somebody tell me why this is a stupid idea because I can't think of any > obvious reason but if there wasn't then I'm sure sombody would have > already done it [0] ... > > Similar principle to mod_perl, a perl script is run but instead of a > normal interpreter being fired up a daemon starts (if it isn't started > already), compiles the perl to bytecode, caches the result and then > executes. Takes slightly longer than the normal interpreter but not > unbearably more. > > Next time a different script is executed the interpreter is already > running and just evals the new script. This should be quicker than a > normal execution. > > The first script is run without having been modified (stat/Fam is your > friend) you just retrieve the bytecode from the cache and execute that. > This should be *much* quicker than normal. sounds like an ideal plan .. the speed of mod perl without the 'this process will be around for years .. if it leaks, you;ll know' sort of problems and also lets you chop and change on the fly .. sounds ace ... is this anything like wot FastCGI does .. or is that summat different? -- Robin Szemeti Redpoint Consulting Limited Real Solutions For A Virtual World
Re: Persistent Perl
On Tue, Jun 12, 2001 at 10:31:44AM +0100, Simon Wistow wrote: > Dominic Mitchell wrote: > > > And you'd have to make the daemon threaded, or end up running multiple > > pre-forking daemons to do the job. At which point, you're only saving > > the fork time and the parse time, which depending on how much effort it > > is to complete the above, may not be much of a saving (passing > > credentials along unix sockets is still pretty slow and non-portable). > > But isn't it roiughly the same scheme that mod_perl uses? And that *is* > demonstrably useful. Roughly, yes, but with a lot fewer details. You could do it on a per-user basis, which would make it simpler. -Dom -- | Semantico: creators of major online resources | | URL: http://www.semantico.com/ | | Tel: +44 (1273) 72 | | Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |
Re: Persistent Perl
Dominic Mitchell wrote: > And you'd have to make the daemon threaded, or end up running multiple > pre-forking daemons to do the job. At which point, you're only saving > the fork time and the parse time, which depending on how much effort it > is to complete the above, may not be much of a saving (passing > credentials along unix sockets is still pretty slow and non-portable). But isn't it roiughly the same scheme that mod_perl uses? And that *is* demonstrably useful. -- simon wistowwireless systems coder only second toughest
Re: Persistent Perl
Dominic Mitchell sent the following bits through the ether: > I think the python scheme of creating a bytecode file on the first run > is better, but I'm not sure how amenable perl's code tree is to being > flattened and restored (this may be why we haven't seen a perl->java > compiler). ByteCache - byte-compile modules when needed The reason we haven't seen a Perl->Java compiler is due to the low-level nature of the JVM and the high-level nature of the PVM. They just don't mix well. Leon -- Leon Brocard.http://www.astray.com/ Iterative Software...http://www.iterative-software.com/ ... I made it foolproof. They are making better fools!
