At 05:09 PM 9/25/00 -0400, Michael Maraist wrote:
> > So, we check for the existence of a C<.plc> file before running a
> > program; if the C<.plc> file is newer than the program, we use that
> > instead. If there isn't a C<.plc> file or it's older than the program,
> > recompile and dump the bytecode to a C<.plc> file. Naturally, this gives
> > us the best speedup for modules which change very, very infrequently,
> > rather than programs which can change a lot during development. Maybe
> > you only want to do this for modules, then.
>
>I suggested this a while ago, and the response was that automatically
>writing files is a security risk.
>You should extend your RFC to describe a caching directory or configuration.
I'd agree. Modules can be byte-compiled at module build time--that's just
dandy. (Having some way to globally rebuild the cached versions would be
nice for users with an appropriate level of authority if, for example, a
new version of perl's got a keener optimizer)
I'd rather programs not automagically save their byte code off (presumably
the user/installer would do this when the program was installed), but I can
see times when it'd be useful. Perhaps it should be optional and only done
if requested with a command-line switch. -C (for cache) perhaps.
You'd also want the startup to check all the dependencies in the bytecode
(in case modules had been updated) and rebuild the cached version if
something was different. That's another reason to not do it, as it'd add
rather more expense to the startup.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
