UPDATE: I've been unclear. Allow me to try again: As I understand it, Perl must be interpretted, rendered as bytecode, and executed. The question is this: how good is that bytecode, and similar/different is it from a compiled binary?
I am asking because if the bytecode generated is good, why can't we distribute the bytecode rather than the source - skipping a run-time step and improving the performance along the way?
This is sounding more and more like a FAQ.
Check out:
perldoc -q compile
Particularly the second item, in perlfaq3;
Key quote:
In general, the compiler will do nothing to make a Perl program smaller, faster, more portable, or more secure. In fact, it can make your situation worse. The executable will be bigger, your VM system may take longer to load the whole thing, the binary is fragile and hard to fix, and compilation never stopped software piracy in the form of crackers, viruses, or bootleggers. The real advantage of the compiler is merely packaging, and once you see the size of what it makes (well, unless you use a shared libperl.so), you'll probably want a complete Perl install anyway.
It is worth noteing that perl6 should minimize many of those issues. My understanding is that the parrot VM executes byte code, and doesn't care whether it comes directly from the perl parser or a saved file. In that way it becomes more like Java. As long as a virtual machine is available, pre-parsed (compiled) scripts will run on it. Perl5 doesn't have a separate virtual machine for each OS, (well, it does but it is closely tied to the parser for each platform,) so the output from the parser is tailored to run on a platform specific VM; a portability nightmare.
In reply to Re: High Performance Perl
by thundergnat
in thread High Performance Perl
by willyyam
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |