Manoj Srivastava <[EMAIL PROTECTED]> writes: > Hi, > > This is what I have heard so far. In the current mechanism > Con: > a) To correctly implement the configuration file, care must be taken > to handle the removed-but-not-purged state, which requires a file > existence test
To clarify: At least one file existence test per package, to a possibly networked file system /usr/share. > b) One needs to make sure that user changes are not discarded. > > Pro: > a) The mechanism is already in place > b) One can put in any code, not just auto loads, in the file loaded at > startup. > > In the new directory proposed, one can put autolodas etc in a > non-configuration file that is loaded at startup > Pros: > a) This file is gone when the package is removed, so no file > existence check is required > b) Simple variable settings can be in the configuration file, and > they shall not harm anything if the file remains after removing > the package [Not strictly true, since there could be two > competing packages that set the same variable, or reset a variable > also used by upstream emacs -- I do not think simple variable > setting are quite as innocent as this] > > Cons: > a) This requires changes in the emacsen common infrastructure > b) For anything other than autoloads, you probably still need > something similar ot the current mechanism anyway -- setting the > load-path, setting some variables that are not private to the > package, creating derived modes, etc. Emacs has subdirs.el, XEmacs has the packaging infrastructure. They solve similar problems. Is there a need to reinvent those wheels? > On the balance, I do not see the benefit. Is a file existence > test so onerous? Does anyone have nay numbers on how long it takes? XEmacs in Debian: [EMAIL PROTECTED]:~$ time xemacs21 -q -batch 2>/dev/null | tail -n3 real 0m1.232s user 0m1.080s sys 0m0.090s [EMAIL PROTECTED]:~$ Standard XEmacs: [EMAIL PROTECTED]:~$ time xemacs-21.4.12 -q -batch 2>/dev/null | tail -n3 real 0m0.637s user 0m0.480s sys 0m0.090s [EMAIL PROTECTED]:~$ Emacs in Debian: [EMAIL PROTECTED]:~$ time emacs21 -q -batch 2>/dev/null | tail -n3 real 0m0.257s user 0m0.210s sys 0m0.020s [EMAIL PROTECTED]:~$ Standard Emacs: [EMAIL PROTECTED]:~$ time emacs -q -batch 2>/dev/null | tail -n3 real 0m0.061s user 0m0.030s sys 0m0.020s [EMAIL PROTECTED]:~$ This is on local file systems and when all of the data is in the cache. A more realistic test would be to flush the cache and try those commands again. Does someone know how to flush the kernel hard disk cache on linux? If the slowdown was a few percent, I wouldn't argue, but the Debian emacs packages slows down startup by a few magnitudes now.
