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!
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
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
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 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]
