[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: native compilation units

From: Lynn Winebarger
Subject: Re: native compilation units
Date: Fri, 3 Jun 2022 10:17:25 -0400

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 <akrl@sdf.org> wrote:
Lynn Winebarger <owinebar@gmail.com> 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?


the compiler can't take advantage of interprocedural optimizations (such
as inline etc) as every function in Lisp can be redefined in every

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

This strategy might be useful, but I guess limited to some specific

Best Regards


reply via email to

[Prev in Thread] Current Thread [Next in Thread]