|Keep It Simple, Stupid
Re: Performance penalties of in-Perl docn vs compiled CGIs.by bliako (Monsignor)
|on Feb 02, 2021 at 11:31 UTC
This is a good question because it touches a controversial subject which more often than not is futile. If Sisyphus was a programmer he would be dealing with these sort of things ...
At least in dealing with it, one can catch up with the developments in a tour-de-force of a module: B::C by Reini Urban. It provides tools to compile Perl, either into C and then to an executable. What, in your terminology, you refer to as "C executables". And whose subtleties were nicely expounded on by GrandFather. There is also the possibility to output to some sort of "bytecode" that Perl uses internally.
You will be able to successfully produce an executable of a simple Perl script thusly:
perl -MO=C,-osimple.c simple.pl
C file equivalent is now written into simple.cgcc simple.c `perl -MExtUtils::Embed -e ccopts -e ldopts`
This will compile the C file (in *nix, please don't bother me with windows - sorry for the harsh way of putting it).
perl -MExtUtils::Embed -e ccopts -e ldopts is very useful and practical. It asks perl to dump all the CFLAGS and LDFLAGS necessary to compile with gcc a C program with embeded perl code. In your current system and specific to the exact perl executable you are calling. (So much better than static environment variables or postit notes.)
Now that was very simple! But when I used a randomly selected perl script from my archive which calls other modules yielded a 25MB C program. I interrupted its compilation a few minutes into it. But it was compiling at least. But at what cost?
Caveat: the motto "only Perl can parse Perl" very frequently pops up in these sort of questions. And rightly so. Without getting into formal proofs without me possesing the proper qualification, consider what will happen if you code eval's a string constant or an external piece of code - unknown at the time of creating C or bytecode. I.e. dynamic parts. Well unless there is a perl embeded in your executable in order to parse that eval and produce a C stub which your C program can dynamically load and call (and that's a theory as in practice you have to pass all the context and program state to that stub), I can't see how you can get over this obstacle. I hear you saying that you don't use evals in your code. Fine but what about any of the modules you are calling? BTW BrowserUK put it succinctly in Re^2: Perl Cannot Be Parsed: A Formal Proof.
If you intend to go this way, could you please report on your findings?