Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

comment on

( [id://3333] : superdoc . print w/replies, xml ) Need Help??

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:

# my %ha = ( 'ha' => 1, 'he' => 2, ); print $ha{'ha'}."\n";
perl -MO=C,-osimple.c

C file equivalent is now written into simple.c

gcc 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?

bw, bliako

In reply to Re: Performance penalties of in-Perl docn vs compiled CGIs. by bliako
in thread Performance penalties of in-Perl docn vs compiled CGIs. by phirun

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.