[comp.lang.perl] a program by any other name...

les@chinet.chi.il.us (Leslie Mikesell) (04/07/90)

In article <1990Apr6.170914.8305@iwarp.intel.com> merlyn@iwarp.intel.com (Randal Schwartz) writes:

>Y'all keep forgetting 'bout "do" and "eval".  The moment you introduce
>those two puppies into the language, you have to have the whole bloody
>Perl compiler in the binary.

But not every program needs run-time variables in eval's or do packages.
(Well, maybe yours do...).

>So, what's the difference between
>spending a few seconds slurping up a program in text form, and
>spending a third of that time slurping up a precompiled version,
>'specially when your code is going to be running for quite a while
>(and may be doing eval's and do's in the process)?  Either way, all of
>the compiler has to be in memory when you launch.

There could be a substantial difference in start-up time on demand-paged
machines even if all the same code ended up in the executable.  The
nature of the parsing pass pretty much guarantees that most of the
executable has to be paged in from disk before any output appears.
Pre-compiled code might be able to generate some visible results with
only a small part of the code paged in.  A simple compromise would be
to dump the memory image of the parsed script (analogous to the
byte-compiled lisp.elc files that GNU emacs uses).  Perhaps these
could automatically be cached somewhere and loaded if the source
script hasn't been changed.
 
>I am actually *glad* that there's not a compiler for Perl... cuz one
>of the things that's neat about Perl is the architecture independence.
>Both Larry and I have four (or more?) arch's on which utils written in
>Perl run *immediately* when installed... no waiting for make or
>nuthin'.  In fact, many times I have considered rewriting an oft-used
>tool in C, but back down because that means I'd have to have four
>binaries sitting around consuming space.

This is a good point - the memory dump would have to be maintained
in a portable format or somehow forced to be kept independently
for each type of machine on a network.

Les Mikesell
  les@chinet.chi.il.us

pcg@aber-cs.UUCP (Piercarlo Grandi) (04/12/90)

In article <1990Apr6.170914.8305@iwarp.intel.com> merlyn@iwarp.intel.com (Randal Schwartz) writes:
  
  Y'all keep forgetting 'bout "do" and "eval".  The moment you introduce
  those two puppies into the language, you have to have the whole bloody
  Perl compiler in the binary.

Just as a matter of saving disk space, we do not need the whole bloody Perl
compiler; in particular we do not need the pure text, which is damn large.

Under Early Unixes there was an 'overlay' image type, which when exec'ed only
loaded the pure text; nowadays this has to be done with GNU Emacs like
technology. Why not, after all? (I do understand that architecture
independence of the impure data and stack would be a minus, but then it
would be just an option, isn't it?).

Well, *if* I find time, I might well steal code from GNU Emacs and modify it
to do a proper undump that does not dump the text image. Actually, now that
I think of it, this would be a nice addition to GNU Emacs itself.
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk