Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.lang.perl
Subject: Re: Compiled perl scripts?
Message-ID: <24627:Mar1506:40:2191@kramden.acf.nyu.edu>
Date: 15 Mar 91 06:40:21 GMT
References: <124823@uunet.UU.NET> <5359:Mar701:28:2991@kramden.acf.nyu.edu> <124847@uunet.UU.NET>
Organization: IR
Lines: 20

In article <124847@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes:
> In article <5359:Mar701:28:2991@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >In article <124823@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes:
> >Please distinguish between INITeX's \dump and the checkpointing provided
> >by certain UNIX implementations. The former makes perfect sense and is
> >always worthwhile. The latter is only occasionally useful.
> You might want to explain the difference.

Inside INITeX, \dump produces a format file (plain.fmt, for example) in
an essentially portable way. The format file contains enough of TeX's
internal state that it ``tex &plain.fmt'' will bring it back to that
state. Of course, the existence of format files implies that Knuth was
careful to keep TeX's internal state sufficiently well organized for
\dump to work.

Typical UNIX checkpointing (viz., a core dump) records lots of
system-specific information, including the entire text of the process.
In relatively unorganized programs this is all you can do.

---Dan