Re^2: Doing a standalone executable (and even a binary!)

[xdg]

It's not really clear if the OP has a question or is just musing. Sounded more like musing over what might be a good approach for standlone perl apps -- but there are really two separate issues that should be kept distinct:

• Packaging up a perl script with an interpreter to run as a standalone
• Storing the compiled perl bytecode so the source isn't recompiled each time

PAR is only an answer to the first, I think. The OP seemed a bit more focused on the second. I'm not sure how much speed gain that really gives, though. It all comes down to the ratio of compile time versus run time. For user apps, I don't know that compile time matters so much.

For the second, mod_perl and PersistentPerl are a couple of approaches used to address this with a persistent perl interpreter.

[Ace128]

How about creating a BINARY? How is the future of that?

[xdg]

I'm not really sure what you mean by "binary".

The real problem is that the whole notion of "compilation" and "executable" are really intertwined in an interpreted language like Perl. Some of what makes Perl easy to code comes from the ability to modify the executable code at runtime by compiling new code that is created during runtime.

The best you're ever going to get to is bytecode that runs on the interpreter -- no different than Python or Java compiled bytecode files that run on their interpreters.

B::Bytecode only takes you so far. As someone else pointed out -- you're probably not going to find what you want until Parrot gets further along.

[Tanktalus]

What the OP is looking for, it seems, is a way to compile your module from .pm to .cpm (compiled perl module) such that next time, perl doesn't need to look at the .pm if the .cpm is newer, and can just load its binary structures directly into memory, skipping the compilation phase completely.

Sounds simple in theory. But, in actual practice, it would likely be very, very time consuming to create the code so that perl could handle this. And the benefit? Probably much smaller than one may think: perl takes so much less time to compile and run than most languages already that any benefits we get here will likely be fairly miniscule. And even these will likely be even less than what mod_perl already does.

All languages, even a theoretical pre-compiled perl language, has startup costs. And, like a precompiled C/C++ binary, perl's startup costs will still exist - eliminating those to become a daemon (or part of another daemon as mod_perl does) will usually get you much more bang for your buck than anything else anyway if startup time is a concern at all.