Re: CVS HEAD fails to build on OSX 10.4 (macterm.c broken?)

[Stefan Monnier]

>     So what is the problem with having *-win loaded by default?
> It isn't really a problem, it just wastes space by making Emacs bigger.
> The tradeoff is that loading it when needed takes time.

> I don't insist on changing it, but did anyone think about the question
> in these terms?

I must say I'm not sure why we do preloading (and dumping), so it's a more
general question.  In my view, there are two main reasons to preload:
1 - startup speed: I think this is clear enough to everybody.
2 - heap size: a bit less obvious; a preloaded package puts some of its
    information (mostly the bytecode) in the `pure' storage which is not
    garbage collected (and is generally slightly more compact, tho this is
    negligible), so the GC'd heap is slightly smaller than if the package
    had been loaded after dumping.
3 - page sharing between processes: the purespace can be shared (by the OS)
    between several Emacs instances.  This is probably a rather rare situation
    nowadays, and the difference is likely to be negligible.
4 - resilience: if the `emacs' binary finds itself all alone (somehow all
    the other .elc files are unreadable/lost), an Emacs with preloaded
    packages is more likely to still be somewhat usable.

Numbers 1,2,3 improve incrementally with each added preloaded package, as
long as that package is almost always used.  For any given package, the
impact is likely to be minor, so measuring the impact of preloading a single
package is likely to be futile (and very difficult because the impact will
be lost in the noise).

Number 4 improves less incrementally.  Emacs may become fully unusable if
some packages can't be found and are not preloaded.  So number 4 seems to
indicate that a package should be preloaded if in some circumstances the
binary may become unusable in the case where the .elc files cannot be found.


        Stefan