Path: utzoo!attcan!uunet!dino!ux1.cso.uiuc.edu!tank!gargoyle!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.lang.perl
Subject: Re: a program by any other name...
Message-ID: <1990Apr7.030242.367@chinet.chi.il.us>
Date: 7 Apr 90 03:02:42 GMT
References: <101155@convex.convex.com> <BLARSEN.90Apr6095532@spider.uio.no> <1990Apr6.170914.8305@iwarp.intel.com>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Chicago Public Access UNIX
Lines: 41

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