Fwd: Re: My ISP refused to install Emacs

I wonder... the DOC file is often causing problems on dual mule/non-mule installations. Do we really want it instead than in the executable ? I don't really think it would use more memory, because of the way VMs work. Quite the contrary, actually, given that it is readonly and hence shareable. OG. From: Erik Naggum <erik(a)naggum.no&gt; Newsgroups: comp.emacs,comp.editors Subject: Re: My ISP refused to install Emacs * Erik Naggum | note: I have not optimized for small, quite the contrary, in fact: | my custom Emacs is dumped with all the documentation strings, so | they take up memory, because I didn't like the DOC file access | patterns. * David Kastrup <dak(a)mailhost.neuroinformatik.ruhr-uni-bochum.de&gt; | Ever tried to move the DOC files from the mountable tape you have them | on to disk? funny you should mention that. I tried that first, but then I noticed that NFS was still a significant drag on performance, so I kept the DOC file open, and only closed it when accessing another file for its doc strings, and then I read and cached entire disk blocks, which I think got into the distributed Emacs, and then I decided that this loading form disk business was really the cause of all the problems. better to trust the paging mechanisms than to open files all the time. and it worked just as I had predicted it would: documentation-string-intensive operations like APROPOS complete in non-detectible time, compared to very much detectible time, and all of it being spent on waiting for NFS servers. on local disks, it still causes a momentary burst of completely unnecessary disk I/O -- Emacs does not even remember the doc strings it has previously read from disk. it's not like it's noticeable on my home machine, a dual 400MHz PII with 512M RAM and 40+G of very fast disks, but on the much smaller and slower machines I deploy the software I write on, stuff like unpredictable network performance is now completely avoided. however, it's noticeably faster on the old 50MHz SPARC with fairly slow disks that is machine with the large displays and stuff, too, so I guess only people who have never actually used mountable tapes could be so goddamn stupid as to think that you'd have to go back that far in technology to notice the wrong-headed design decision to optimize for fast disks and little memory, which is really what's behind the decision not to dump with documentation strings, so I think this is tad more significant than you do, obviously, but I hope you have a less idiotic comment to come up with in reply, OK? #:Erik -- SIGTHTBABW: a signal sent from Unix to its programmers at random intervals to make them remember that There Has To Be A Better Way.