Thanks. There was a thread in January starting at https://lists.gnu.org/archive/html/emacs-devel/2022-01/msg01005.html that gets at one scenario. At least in pre-10 versions in my experience, Windows has not dealt well with large numbers of files in a single directory, at least if it's on a network drive. There's some super-linear behavior just listing the contents of a directory that makes having more than, say, a thousand files in a directory impractical. That makes packaging emacs with all files on the system load path precompiled inadvisable. If you add any significant number of pre-compiled site-lisp libraries (eg a local elpa mirror), it will get worse. Aside from explicit interprocedural optimization, is it possible libgccjit would lay out the code in a more optimal way in terms of memory locality? If the only concern for semantic safety with -O3 is the redefinability of all symbols, that's already the case for emacs lisp primitives implemented in C. It should be similar to putting the code into a let block with all defined functions bound in the block, then setting the global definitions to the locally defined versions, except for any variations in forms with semantics that depend on whether they appear at top-level or in a lexical scope. It might be interesting to extend the language with a form that makes the unsafe optimizations safe with respect to the compilation unit. On Wed, Jun 1, 2022 at 9:50 AM Andrea Corallo wrote: > Lynn Winebarger writes: > > > 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? > > Hi, > > the compiler can't take advantage of interprocedural optimizations (such > as inline etc) as every function in Lisp can be redefined in every > moment. > > You can trigger those optimizations anyway using native-comp-speed 3 but > each time one of the function in the compilation unit is redefined > you'll have to recompile the whole CU to make sure all changes take > effect. > > This strategy might be useful, but I guess limited to some specific > application. > > Best Regards > > Andrea >