Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Precompiled perl...

by Eyck (Priest)
on Oct 27, 2004 at 09:02 UTC ( #402933=perlquestion: print w/replies, xml ) Need Help??
Eyck has asked for the wisdom of the Perl Monks concerning the following question:


Most not-completely-compiled languages provide a way of caching compilation - through the use of pre-compiled libraries/programs/stuff ( lisp, python, java etc use such solutions )

Why doesn't perl pre-compile often-used things?


The way I see it, "Bytecode" support in perl is just a toy, and a way to show off the flexibility of the language.

What is missing is in-perl support for parse trees, something that would bypass whole compilation phase, and that would include libraries support.

This would have quite remarkable effect on perl

  • REALLY improved startup time for apps that use lot of libraries
  • for sysadmins - reduced cost of perl in cron
  • lower resources required for running perl, thus, perl on embeded machines starts making sense
  • PAR - such bytecode support would turn ingenious PAR into relatively simple excercise. (OTOH, experiences with PAR suggest that it might not be that easy..)

What bugs me, is the fact that when perl was being created, such pre-compiled bytecode support was en-vogue, lisp did it etc.. And since perl internally uses bytecode/parse tree, it would be trivial to add. What is the reason for that?

Replies are listed 'Best First'.
Re: Precompiled perl...
by borisz (Canon) on Oct 27, 2004 at 09:26 UTC
    It is possible to get this precompiled thing already. It is called bytecode.
    # build a precompiled bytecode script named xyz perl -MO=Bytecode,-H,-oxyz -e 'print "moin\n"' # the script can be called with this line perl xyz
      Yeah, but what about pre-compiled libraries,

      What I would like to achieve is to have all /usr/share/perl5 pre-compiled, this could be very nifty..

        Not really. Other people have reported that it tends to be slightly more expensive to load a perl program from compiled form than from original source code. I wouldn't spend too much time worrying about this problem. Things like mod_perl exist so that the compilation process happens once and then the in-memory program is just re-used. That avoids the cost of *both* scenarios.
Re: Precompiled perl...
by PodMaster (Abbot) on Oct 27, 2004 at 09:37 UTC
    You are talking about "bytecode", and there exists ByteLoader/B::Bytecode, but it is HIGHLY EXPERIMENTAL. USE AT YOUR OWN RISK (note the caveats). Once it becomes stable perl might start caching bytecode, but chances are it will never happen with perl5 as we know it (but it probably will with perl5 under parrot, aka ponie). Why? I don't know, but my guess is as good as any. Take your pick
    • didn't think of it early enough
    • not enough funding
    • not enough interest
    • general perl5 maintenance cruft

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

Re: Precompiled perl...
by crenz (Priest) on Oct 27, 2004 at 12:46 UTC

    Just for fun, I „compiled“ via B::Bytecode into a I then timed execution of perl -MWx -e '' vs. perl -MWxbc -e '' to compare module load times.

    The result: Both consistently take about half a second to start on my PowerBook, with the original being consistently very slightly faster.

Re: Precompiled perl...
by htoug (Deacon) on Oct 28, 2004 at 07:41 UTC
    It is part of the plans for Perl6/Parrot. The parrot byte code should be compact enough to be able to be loaded faster than the original program.

    That is not the case in Perl5, where the byte code is just a serialization of the internal syntax tree and is tightly integgrated (in obscure ways) with the compiler. AFAICR is has been discussed several times and been given up as nearly impossible. Grahams Barr's attempts at a perl compiler has given us the B:: namespace, that contains many useful modules, but no compiler that speeds up loading.

    You do have to load the entire perl compiler to be able to interpret eg evals, requires and uses, so the loadtime will be high whatever you do.

      The point of this excercise is not to get rid of loading perl compiler, but bypassing compilation of whole lot of code ( AFAIK "use Sth" compiles Sth, and then compiles everything that Sth depends on. If you've got your Sth already compiled into parse tree, then you just load your parse tree and go on with execution ).
Re: Precompiled perl...
by DrHyde (Prior) on Oct 28, 2004 at 08:44 UTC
    it would be trivial to add

    If it's trivial, how about you stop whining and DO IT.

      have you actually read what I wrote?

      I said it would be trivial for the people who were creating perl AT THAT time. And that would probably be Larry Wall, and would require time travel.

      And one should research such problems FIRST, and that's exactly what I'm doing here.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://402933]
Approved by pelagic
Front-paged by htoug
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (3)
As of 2017-02-20 00:52 GMT
Find Nodes?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?

    Results (293 votes). Check out past polls.