[metafont] Re: [metapost] TeX and MF: Fast-loading of core image

[Marcus Brinkmann]

At Wed, 5 Jan 2005 18:23:08 +0100 (MET),
Laurence Finston <lfinsto1 at gwdg.de> wrote:
> On Wed, 5 Jan 2005, Taco Hoekwater wrote:
> 
> > If you really want to try to implement dumping, look for 'ready_already'
> > in the web source, and combine the code & explanation at those locations
> > with the code & explanation from the README in that archive I gave you
> > the link to. If that doesn't help you figure it out, nothing else will.
> >
> 
> That sounds like good advice, thanks.  The README in the
> archive didn't explain much, so I'll have to have a look at
> the code when I get a chance.
> 
> Thanks to everyone who's responded.  I'm still interested,
> in case anyone else has something to say on the subject.
> However, the upshot of your responses seems to be that it
> would be A) difficult and B) unnecessary, so maybe I won't
> do it after all.  Things seem to have been going downhill
> ever since they invented punch cards.

Now, this is getting off-topic, but for what it's worth, I want to
reaffirm what the other people said: You don't really want to do it.
You don't want to do it.  Repeat with us :)

The reason is that any such approaches are extremely fragile.  I know,
because I am working on operating systems, and our own system
(GNU/Hurd) had problems with getting emacs to work, and this although
we use the same C library and build tools as GNU/Linux, just because
of some differences in the setup of our malloc.  There are very subtle
issues involved you don't even want to learn about if you can avoid
it.

Another thing to consider is (forward) binary compatibility: If you
dump the executable image, you lose all advantages of dynamic linking,
as your binary will effectively be statically prelinked.

Portability will suffer extremely, and this is a real concern for many
projects.  For example, there may be obscure systems where such an
approach is not really possible or very complicated (I have not really
thought much about it, but well, let's say systems without virtual
memory management, where you would have to re-load your dumped
executable at the same address each time).

Now, I said you don't want to go back that road, but that doesn't mean
there aren't alternatives.  What you would probably do today to
achieve a similar effect is maybe something like orthogonal
persistency, where certain tasks just stay in memory across reboots.
Then implement tex as a daemon, and run it persistently in the
background :) Things like that are much more complicated, but also
potentially more powerful.  I don't think it is worth the trouble for
tex, but there are other applications were it makes a crucial
difference, however, it is usually more because of user interaction
issues rather than load time.  (A cheap version of this is done with
office packages, which are auto started in the background so they pop
up quickly when you want to start to work).

The GNU linker supports the concept of pre-linking, which also seems
relevant here, but it is for dynamic linking optimization.  If you can
dump tex formats as dynamic objects rather than static executables,
you could take advantage of that concept here.  Just a crazy idea that
just occured to me.

Of course, just dumping the internal state in some
application-specific format you can quick-load later is probably
simplest.

Doing weird things should be justified by more than nostalgy :) Often
it is easier to swim with the current and use proven techniques.

Have fun,
Marcus