Hi,
Since the native compiler does not support linking eln files, I'm curious if anyone has tried combining elisp files as source code files and compiling the result as a unit?
Has there been any testing to determine if larger compilation units would be more efficient either in terms of loading or increased optimization opportunities visible to the compiler?
Just as a thought experiment, there are about 1500 .el files in the lisp directory. Running from the root of the source tree, let's say I make 2 new directories, ct-lisp and lib-lisp, and then do
cp -Rf lisp/* ct-lisp
echo "(provide 'lib-emacs)" >lib-lisp/lib-emacs.el
find lisp -name '*.el' | while read src; do cat $src >>lib-lisp/lib-emacs.el; done
EMACS_LOAD_PATH='' ./src/emacs -batch -nsl --no-site-file --eval "(progn (setq load-path '(\"ct-lisp\" \"lib-lisp\")) (batch-native-compile 't))" lib-lisp/lib-emacs.el
find lisp -name '*.el' | while read src; do
cat >lib-lisp/$(basename $src) <<EOF
;; -*-no-byte-compile: t; -*-
(require 'lib-emacs)
EOF
./src/emacs --eval "(setq load-path '(\"lib-lisp\"))" &
This is just a thought experiment, so assume the machine running this compilation has infinite memory and completes the compilation within a reasonable amount of time, and assume this sloppy approach doesn't yield an divergent metarecursion.
If you actually loaded all 1500 modules at once, what would be the difference between having 1500+ files versus the one large so (assuming all 1500+ were compiled AOT to be fair).
I'm assuming in practice you would want to choose units with a bit more care, of course. It just seems like there would be some more optimal approach for using the native compiler than having all these tiny compilation units, especially once you get into any significant number of packages.
Lynn