Re: Bug#193439: emacsen-common: debian-emacs-policy and package setup in conffile

[Simon Josefsson <jas@extundo.com>]

Manoj Srivastava <srivasta@debian.org> 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:

jas@latte:~$ time xemacs21 -q -batch 2>/dev/null | tail -n3
 
 
real    0m1.232s
user    0m1.080s
sys     0m0.090s
jas@latte:~$

Standard XEmacs:

jas@latte:~$ time xemacs-21.4.12 -q -batch 2>/dev/null | tail -n3
 
real    0m0.637s
user    0m0.480s
sys     0m0.090s
jas@latte:~$

Emacs in Debian:

jas@latte:~$ time emacs21 -q -batch 2>/dev/null | tail -n3
 
real    0m0.257s
user    0m0.210s
sys     0m0.020s
jas@latte:~$

Standard Emacs:

jas@latte:~$ time emacs -q -batch 2>/dev/null | tail -n3
 
real    0m0.061s
user    0m0.030s
sys     0m0.020s
jas@latte:~$

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.