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