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

[Daniel Colascione <dancol@dancol.org>]

On 01/10/2014 11:15 AM, Eric S. Raymond wrote:
> 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.

Disagree. As other benchmarks in this thread indicate, dumping is still 
a very useful optimization. Besides: the build complexity is 
well-understood.

> 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.

Not everyone has an SSD.

> There are good reasons to think about dropping this technique:
>
> (1) It makes cross-build of Emacs a pain in the ass.

Meh?

> (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.

That's why the XEmacs portable dumper is better than the current Emacs 
setup. But not by enough to get distracted with ripping the guts out of 
the system.

>
> (4) We're presently buying some startup speed at the cost of a larger
>      minimum working set.

The minimum working set is zero. Modern operating systems demand-page 
necessary information. The dumped information is file-backed, so the 
commit charge is zero as well.

>      under modern cache hierarchies, but I think the question deserves
>      examination.

Unless circumstances have materially change (as they would if, say, 
non-volatile main memory became common), I don't want to waste time 
rehashing old debates.