eay@surf.sics.bu.oz (Eric the Young) (03/20/90)
In article <100628@convex.convex.com> tchrist@convex.COM (Tom Christiansen) writes: >In article <1990Mar16.010322.18464@tc.fluke.COM> inc@tc.fluke.COM (Gary Benson) writes: >> 1. It seems that perl scripts are compiled just prior to execution. >> Would there be any benefit to a perl compiler that, like C, would >> JUST do the compilation and create a file (a.out might be a cool name >> or maybe p.out). This way, I could store the executable somewhere and >> not have to recompile each and every time. > >Well, you can compile it, sort of, using the dump operator or the -u >flag. I really love the speedup I get from a dumped perl script, but the >disk space of including all of perl in each one is almost always >prohibitive. I would like perl to dump JUST the dataspace and enough >special text that says to re-invoke itself in a way indicating that it >should load its data from this file. If the time taken during startup is the parsing, surely perl could be made to dump an image of the compiled program (pl-code :-) that could be reloaded very quickly with minimal parsing. If the file was acsii it could still be invoked via #!/bin/perl -pl_code_flag on the first line. A 500 line perl script becomes n lines of semi-random-ascii. How much of a saving this would be I don't know, since I don't have undump and I have not done any profiling on large perl scripts (yet :-) to find out the startup costs. I also don't know how much of the startup time is just spend mallocing variables, etc, etc, so there may be no real saving unless you save an image of the heap. eric (a novice perl hacker) -- Eric Young | I owe, I owe, System Programmer, SICS Bond Uni.| So off to work I go. ACSnet: eay@surf.sics.bu.oz.au |
al@ee.pitt.edu (Alan Martello) (03/22/90)
I run into the problem that I need to run perl on a variety of
platforms. Unfortunately, some don't have perl installed and
I can't twist enough arms to make that happen. However, I would
love to / almost need to run perl scripts on them.
A few possibilities:
1) do an undump -- this is system dependent and cannot always
be done easily (I have yet to get it to work for hello_world.c
on my Sun under SunOS 4.0.1); in addition, I can't do a dump
for a DecStation from my Sun.
2) copy the "minimal perl stuff" -- the problem here is that
the minimum includes stuff in the compiled in system
libaries (which I don't have on my other platforms).
3) the most desirable approach would be a "run-time" perl
which could NOT compile perl scripts, but could only run
"compiled" perl scripts. Ideally, this would be PORTABLE
across system types. I realize this may mean addressing the
question like "what if one system has a certain system call
and another doesn't". The answer which I'd give is to allow
ALL systems to perform all calls and when the "compiled" perl
is loaded, a check is first made by the "run-time" perl
to determine if it can perform all necessary functions
utilized by the script.
Would anyone else like to see 3) above? Anyone have any idea
how hard it would be to implement? Is there an internal state
after parsing the perl source which can be easily output and
re-read later to re-create the previous perl environment in a
"machine-independent" way?
*******************************************************************
Alan R. Martello Electrical Engineering Dept.
al@ee.pitt.edu University of Pittsburgh
*******************************************************************tchrist@convex.COM (Tom Christiansen) (03/22/90)
In article <903@surf.sics.bu.oz> eay@surf.sics.bu.oz (Eric the Young) writes: >If the time taken during startup is the parsing, surely perl could >be made to dump an image of the compiled program (pl-code :-) that could >be reloaded very quickly with minimal parsing. If the file was acsii >it could still be invoked via #!/bin/perl -pl_code_flag on the first line. >A 500 line perl script becomes n lines of semi-random-ascii. >How much of a saving this would be I don't know, since I don't have >undump and I have not done any profiling on large perl >scripts (yet :-) to find out the startup costs. Here are some random timings from a Convex C1: % ll /usr/bin/perl man man.perldump -rwxrwxr-x 1 root 466288 Mar 16 04:55 /usr/bin/perl -rwxr-xr-x 1 tchrist 18901 Mar 21 21:44 man -rwxrwxr-x 1 tchrist 777584 Mar 21 22:01 man.perldump % wc man 776 2425 18901 man # plus 74 lines of include files (getopts and stat) % time ./man -v ./man: version is "man 0.7 90/03/21 21:41:51" 1.2u 0.3s 0:03 51% 0+0k 51+0io 112pf+0w % time ./man.perldump -v ./man: version is "man 0.7 90/03/21 21:41:51 (compiled)" 0.0u 0.2s 0:00 650% 0+0k 0+0io 44pf+0w While on a C2 0.3+0.1 for the interpreted version (better stated: the freshly parsed) and 0+0 on the other one. One second is just enough of a delay to start to bother me. However, I find that the initial load of the dumped version sometimes takes a LONG time, although this is reflected only in the real, not the user or system time. I sure do like Eric's idea here though. perl4? --tom -- Tom Christiansen {uunet,uiucdcs,sun}!convex!tchrist Convex Computer Corporation tchrist@convex.COM "EMACS belongs in <sys/errno.h>: Editor too big!"