Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: Performance penalties of in-Perl docn vs compiled CGIs.

by bliako (Monsignor)
on Feb 02, 2021 at 11:31 UTC ( [id://11127808] : note . print w/replies, xml ) Need Help??


in reply to Performance penalties of in-Perl docn vs compiled CGIs.

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:

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

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

Replies are listed 'Best First'.
Re^2: Performance penalties of in-Perl docn vs compiled CGIs.
by LanX (Saint) on Feb 02, 2021 at 14:57 UTC
    > subject which more often than not is futile.

    The benefits are too small or non-existant. This whole .plc mechanism was invented back in the days when RAM was sparse and processors slow,hence the compilation phase was a considerable factor.

    Turning a Perl process into a persistent demon solves most, if not all use cases nowadays. That's because IO is now most limiting factor, and neither compile-phase nor IO needs to be redone.

    I have trouble imagining a use case where pre-compilation would pay off, because this would still be hampered by IO.

    The only aspect where pre-compilation tends to be used is obfuscation to protect the code. But that's also mostly wishful thinking.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery

    ) RAM-Disk? Seriously?

      because IO is now most limiting factor

      Right. Given also that for 200 lines of Perl (+ 3rd party modules) I got back a 25MB C program which I don't dare to imagine what executable size will yield and when.

        > I got back a 25MB C program

        That's because a compiled run-time will have to carry most if not all of Perl.exe with it.

        > which I don't dare to imagine what executable size will yield and when.

        I think there is an upper limit/plateau once all features are bundled.

        Now ... lets suppose a use case where we needed to restart hundreds of Perl scripts as fast as possible:

        A "master-demon" holding the sources, compiling,forking and killing other demons is most probably more efficient.

        For instance:

        A webserver in combination with FCGI can be seen as such a "master-demon".

        And mod-perl is the variant where different scripts are sharing the same run-time (with the complication to avoid conflicts to minimize the footprint)

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery

Re^2: Performance penalties of in-Perl docn vs compiled CGIs.
by phirun (Novice) on Feb 02, 2021 at 13:35 UTC
    Hey, thanks for a most thoughtful and informative reply, bliako. Yes, I figured that I was asking the sort of "dumb question" inevitable for amateurs and dilettantes in any subject. I've always regarded Perl as a major intellectual accomplishment, and its internal complexity and inner convolutions make traditional compilation far more difficult than the simplistic assumptions of my question, if I understand you correctly.

    So be it! Once written in Perl, it stays in Perl! I can live with that. And the analogue of Sisyphus describes VERY nicely my own view of coding as a profession, which is why I went with hardware. So no, NO WAY am I intending to "go this way". Simply lack the courage.

      By all means I did not try to discourage you. The method to compile is so simple you may as well give it a try.

        > I did not try to discourage you ... may as well give it a try.

        Not at all discouraged and yes, I'll play around with the code examples you've given. I've never used eval's and don't bother with modules other than standard ones, since I find that the effort of learning them is usually better spent writing your own.

        But the new project will shortly involve others, so I've decided to take a look at solutions I've previously avoided as being better suited to group efforts.