Darryl> What you *can* do, with code modifications, is to Darryl> redump (recreate, not add to) XEmacs with your local Darryl> changes. This appears to be what GNU Emacs is doing in Darryl> the wiki, and you should be able to use a similar Darryl> procedure with XEmacs, too. In the sense that it's not simply open ("/path/to/emacs", "w+"), of course you're right---GNU loads the whole file, adds code in RAM, then unexec's the whole memory image. However, for GNU it will be as much as 2 orders of magnitude faster than for XEmacs/pdump, which can't use preloaded LISP for the process because of the difference between xemacs -nd initialization and xemacs initialization. In the script posted on the wiki, I would guess that GNU Emacs starts in 3-5 seconds with an up-to-date fast-emacs, and in 10-20 seconds with a rebuild. By comparison the same numbers for XEmacs are probably more like 5-10s and 150-250s. As I wrote in my reply to Mr. Clemens, I don't think trying to emulate GNU is an appropriate strategy for XEmacs, but you can see the attraction if you start a fresh emacs often. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

Olivier Galibert <galibert(a)pobox.com&gt; wrote: Yes, I took a quick look at doing this, a month or two back, and I quickly ran into the problem of not being able to dump out window structures ;-(. Darn. It would have been soooo cool to be able to redump from a running XEmacs. Arguably, the next best approach is to use the portable dumper, and allow optionally specifying an arbitrary dump file (i.e, the standard dump file would normally be used, but the user could make a new dump and then use that dumpfile). By using the portable dumper, you don't need to keep temacs around. I modified my local XEmacs to allow the optional specification of pdump files (via a command-line option), but my changes are currently intertwined with lots of pdump debugging code (which you don't want). -- Darryl Okahata darrylo(a)soco.agilent.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day.

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; wrote: Oh, yes, and it just gets worse with newer 64-bit systems (as someone's got to port/twiddle unexec). For these, it's often easier to just use pdump. Well, this *is* the same as redumping from scratch, except that the user can then tell XEmacs to use his (private) pdump image. It's not a matter of saving some trivial amount of disk space -- it's a matter of being able to do it at all. Note that, for some systems, unexec doesn't work, and so pdump has to be used. Now, if you have root access, and you're the only one using the workstation, there's probably no problem; you just rebuild XEmacs using the current procedures (but also include additional stuff via site-load, etc.). However, if you don't have root access, or are on a multi-user system, then specifying a pdump image is the only way (which you currently cannot do). Yup, this is a definite problem, and there's currently no solution for this. -- Darryl Okahata darrylo(a)soco.agilent.com DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day.

clemens> This kind of preloading is common for all clemens> not-just-for-fun lisp implementations, We have preloading. However our design has other desiderata than minimal dumping and startup time, as initializing the LISP engine is not the binding constraint on startup time any more. (See below.) clemens> When you look at clemens> http://www.emacswiki.org/cgi-bin/wiki/DumpingEmacs it clemens> seems that the FSF emacs world also follows this path. Well, I don't know how other LISPs do it. GNU Emacs uses the unexec strategy, which in the current OS ferment takes up a pile of developer time keeping up with various kernel, processor, and toolchain quirks, as well as deliberate features like random load addresses used in secure kernels. If unexec works at all, since it simply reloads a memory image into the same place, it probably works fairly well for your application. XEmacs does have unexec functions, but on most platforms they are deprecated in favor of the portable dumper. However, I would consider any dumping strategy extremely dangerous for use in any fashion other than batch due to references to external state (see below). And in fact that's the way the wiki describes it: rebuilding the binary at startup time. It would be easy enough to do that with site-load.el and maybe small mods to dumped-lisp.el (eg, to put the site-package list in $HOME) in XEmacs. clemens> I already spotted that, but I can't use the require clemens> directive here. Probably dumped-lisp.el works, but clemens> actually I think redumping is much nicer. flies in the face of modern OS design. For example, if you want an exact memory image that starts up fast, use your box's "suspend to disk" function. In practice, what I might want is preloading of some common applications. It takes less than 5 minutes to redump the whole liston a 450MHz PII with a 66MHz bus and crummy drives, and since my typical session runs for approximately 1000 times that long, who cares? Not me, anyway! On the other hand, I don't want to dump a session that has been running for three weeks and contains 100MB of buffer and LISP data. So in the context of my application, I have to disagree with you; redumping is merely cute. You'll also find that you get much less speedup from such optimizations in XEmacs than you will from GNU Emacs. GNU Emacs is intended to be a monolithic application which you can tune to your needs. XEmacs takes the modern (not necessarily "better", though) approach of being intentionally modular, using lazy loading throughout, an approach tuned for an application that is expected to run for a very long time. XEmacs spends time at startup investigating the local layout of libraries, and that's where most of XEmacs startup time goes. clemens> Still, not having any pdump_root_lisp_objects is clearly clemens> a bug. No, pdump is a special facility designed for use in this way. If you have a better idea, feel free to implement it. But pdump as designed has been a huge success in terms of minimizing developer time spent on unexec bugs and in terms of giving us "free" ports to platforms with established userlands running over kernels that we don't have expertise in writing unexec for (eg, Darwin). Serendipitously, it has also provided the foundation for a whole suite of new approaches to garbage collection. clemens> Naive approach: Is it feasable to use the root list as it clemens> was at the time the original dump was made, or do we have clemens> to reinitialize it? Olivier (who is the expert) said probably not, but you're welcome to try. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.