Time to drop the pre-dump phase in the build?

[Eric S. Raymond]

My current transition task is still tag cleanup and signing. I'll
report on that shortly.

I had some off-list conversation with one of our lurkers about
tag cleaning. During it he made an interestingly radical suggestion:
Maybe it's time to stop pre-dumping compiled Lisp into the Emacs build.

While this made sense as a performance hack back in the day, hardware
(most relevantly disk I/O) is much, *much* faster now.  And SSDs are
making access to disk not much slower than main memory. Compilation
on demand might be fast enough today.

There are good reasons to think about dropping this technique:

(1) It makes cross-build of Emacs a pain in the ass.

(2) Even in the non-crossbuild case, it requires a whole lot of
    build-system hair we could otherwise do without.

(3) Back when I last looked at it (admittedly a long time ago) 
    the dump code was both the largest single source of porting
    problems and a serious attractor of crash bugs.  

(4) We're presently buying some startup speed at the cost of a larger
    minimum working set.  I don't *know* that this is a bad trade
    under modern cache hierarchies, but I think the question deserves
    examination.

If anybody wants to own this problem, comparative benchmarking seems
like a good place to start.  That is, hard numbers about the 
actual performance effects of pre-dumping.  That'd head off a
lot of arguments, anyway.

(Why, yes.  I *do* enjoy shaking up peoples' long-held assumptions.
This wasn't obvious already?)
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

Every election is a sort of advance auction sale of stolen goods. 
        -- H.L. Mencken