Yes, perlcc exists and can gain you some speed, but what it mainly is is a compiled dispatcher so that the byte-code doesn't have to be generated and parsed. The real work is still done by calling into the code for the perl operators.

Also notice that perl does quite a bit by evaluating code at runtime, so the interpreter is still needed even in compiled programs.

Still, it is true that initial perl load and code compile take a noticeable time if afterward very little running will be going on. This isn't a problem if a piece of code only runs once, but gets painful if it's run very often (e.g. typically seen in CGI). The generally used solution for this is in the perl world is persistent interpreters. For that, look at things like (for CGI) mod_perl, FastCGI and (generally useful) SpeedyCGI

When in your question you referred to apache holding the compiled code, you were probably talking about mod_perl. And since you wanted to apply that generally, SpeedyCGI is probably the answer you were looking for. Notice that there is no real need to have this kind of functionality builtin. These modules demonstrate that you can get the effect purely from what already exists.

Neil

Basically the process to run a Perl script starts with a parser that will read your script and understand what you wrote, than this parsed tree will be optimized, than a bytecode is created, and this bytecode is what the Perl interpreter will run.

You mentioned Apache, well, what Apache does is just a Perl interpreter that doesn't die, the Apache process will stay running, so, you just resume a Perl script, that actually is not a script, is a mod_perl module that has a framework to follow.

If what you want is to create an executable, in other words, do not need to have the Perl interpreter installed to run your script, you can take a look in this modules: PAR, App::Packer, LibZip.

What this modules above will do is to create a binary of the Perl interpreter with your script inside, and the interpreter will run automatically your code when executed, basically is that.

Now if what you want is to make the load process of your script faster, in Perl5 the idea to save the bytecode to run it directly doesn't work very well, since the load process of a code is not just the creation of a bytecode, but we can load libraries (XS code, DLL), and we change the status of the interpreter that are not represented in the bytecode, like the IO status, let's say an file openned. But this will work very well on Perl6, but you will need to wait for it.

So, to make the load process faster we always use the idea of a persistent interpreter, like with the of FastCGI, mod_perl and pperl.

PAR, while a fine and handy tool, does not compile perl code (as I understand it). It simply bundles your script with the modules that it needs, along with a perl runtime, into an executable.

While that difference could be considered somewhat pedantic, consider the original poster's query. The observation was made that perl always reparses and recompiles on each invocation. PAR does not avoid that. In fact it adds another layer to it, since your code, and the included modules, are kept in a zip (-like?) format, and everything needs to be decompressed before parsing and compiling. I routinely use ActiveState's perlapp, and it does produce an executable that's often much faster than those produced by PAR, but I don't know if it's doing any parsing or compiling before emitting the exe.

Perhaps, the shift to Parrot with make this easier. I'm guessing it will be easier under parrot to snag byte code out of mid air and put it into a file, than it is under the current internals, but that remains to be seen.