[I ditched review from the CC'es]
Olivier Galibert <galibert(a)pobox.com> writes:
Some statistics you may find interesting, for a run of xemacs -q in
my
local configuration (most, but not all, of the packages):
site-start stats : 210
This is weird
1. After scanning the packages the locate-file cache should be
filled and scanning the tree should be cheap shouldn't it?
2. If you _have_ site-start.el it should be in ../site-packages/lisp
which should be very early in the search sequence.
auto-autoloads stats : 270
Sucessful auto-autoload.el* stats are systematically followed by a
fstat.
Some interesting excerpts:
[5 stats for one auto-load removed]
Looks like there is some room for improvement even without
affecting
flexibility.
The problem is that XEmacs is still doing the generic loading code at
startup this includes such stuff as checking for outdated .elc files
etc. IMHO XEmacs should just try to open
../lisp/package-name/auto-autoloads.elc and handle any errors. No
stats required.
Then one should get rid of the stupid double loading the mule coding
does (if you do this at C level the first 3000 byte will typically
still be in the stdio stream buffer and no additional I/O is
required).
Long term I think the format of the .elc files should be rethought.
Why is it a lisp file?
Jan