Re: native compilation units

[Eli Zaretskii]

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Fri, 3 Jun 2022 10:17:25 -0400
> Cc: emacs-devel@gnu.org
> 
> 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.

Is this only on networked drives?  I have a directory with almost 5000
files, and I see no issues there.  Could you show a recipe for
observing the slow-down you are describing?

> 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.

ELPA files are supposed to be compiled into the user's eln-cache
directory, not into the native-lisp subdirectory of lib/emacs/, so we
are okay there.  And users can split their eln-cache directory into
several ones (and update native-comp-eln-load-path accordingly) if
needed.

But I admit that I never saw anything like what you describe, so I'm
curious what and why is going on in these cases, and how bad is the
slow-down.

> 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.

I believe this is an entirely different subject?