Re: native compilation units

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Unfortunately sometimes we have to cope with environment we use.  And for
> all I know some of the performance penalties may be inherent in the
> (security related) infrastructure requirements in a highly regulated
> industry.

What we learned at the end of last century is exactly that there aren't
any such *inherent* performance penalties.  It may take extra coding
work in the file-system to make it fast with 10k entries.  It may take
yet more work to make it fast with 10G entries.  But it can be done (and
has been done), and compared to the overall complexity of current
kernels, it's a drop in the bucket.

So nowadays if it's slow with 10k entries you should treat it as a bug
(could be a configuration problem, or some crap software (anti-virus?)
getting in the way, or ...).

> Not that that should be a primary concern for the development team, but it
> is something a local packager might be stuck with.

Indeed.  Especially if it only affects a few rare Emacs users which
don't have much leverage with the MS-certified sysadmins.

>> >> [ But that doesn't mean we shouldn't try to compile several ELisp files
>> >>   into a single ELN file, especially since the size of ELN files seems
>> >>   to be proportionally larger for small ELisp files than for large
>> >>   ones.  ]
>> >
>> > Since I learned of the native compiler in 28.1, I decided to try it out
>> and
>> > also "throw the spaghetti at the wall" with a bunch of packages that
>> > provide features similar to those found in more "modern" IDEs.  In terms
>> of
>> > startup time, the normal package system does not deal well with hundreds
>> of
>> > directories on the load path, regardless of AOR native compilation, so
>> I'm
>> > tranforming the packages to install in the version-specific load path,
>> and
>> > compiling that ahead of time.  At least for the ones amenable to such
>> > treatment.
>>
>> There are two load-paths at play (`load-path` and
>> `native-comp-eln-load-path`) and I'm not sure which one you're taking
>> about.  OT1H `native-comp-eln-load-path` should not grow with the number
>> of packages so it typically contains exactly 2 entries, and definitely
>> not hundreds.  OTOH `load-path` is unrelated to native compilation.
>>
>
> Not entirely - as I understand it, the load system first finds the source
> file and computers a hash before determining if there is an ELN file
> corresponding to it.

`load-path` is used for native-compiled files, yes.  But it's used
in exactly the same way (and should hence cost the same) for:
- No native compilation
- AOT native compilation
- lazy native compilation
Which is what I meant by "unrelated to native compilation".

> Although I do wonder if there is some optimization for ELN files in the
> system directory as opposed to the user's cache.  I have one build where I
> native compiled (but not byte compiled) all the el files in the lisp
> directory,

IIUC current code only loads an ELN file if there is a corresponding ELC
file, so natively compiling a file without also byte-compiling it is
definitely not part of the expected situation.  Buyer beware.

>> I also don't understand what you mean by "version-specific load path".
> In the usual unix installation, there will be a "site-lisp" one directory
> above the version specific installation directory, and another site-lisp in
> the version-specific installation directory.  I'm referring to installing
> the source (ultimately) in ..../emacs/28.1/site-lisp.  During the build
> it's just in the site-lisp subdirectory of the source root path.

I'm not following you.  Are you talking about compiling third-party
packages during the compilation of Emacs itself by placing them into
a `site-lisp` subdirectory inside Emacs's own source code tree, and then
moving the resulting `.el` and `.elc` files to the `../NN.MM/site-lisp`
subdirectory in Emacs's installation target directory?

And you're saying that whether you place them in `../NN.MM/site-lisp`
rather than in `../site-lisp` makes a significant performance difference?

>> Also, what kind of startup time are you talking about?
>> E.g., are you using `package-quickstart`?
> That was the first alternative I tried.  With 1250 packages, it did not
> work.

Please `M-x report-emacs-bug` (and put me in `X-Debbugs-Cc`).

> First, the file consisted of a series of "let" forms corresponding
> to the package directories, and apparently the autoload forms are ignored
> if they appear anywhere below top-level.  At least I got a number of
> warnings to that effect.
> The other problem was that I got a "bytecode overflow error".  I only got
> the first error after chopping off the file approximately after the first
> 10k lines.  Oddly enough, when I put all the files in the site-lisp
> directory, and collect all the autoloads for that directory in a single
> file, it has no problem with the 80k line file that results.

We need to fix those problems.  Please try and give as much detail as
possible in your bug report so we can try and reproduce it on our end
(both for the warnings about non-top-level forms and for the bytecode
overflow).

> I'm pretty sure the load-path is an issue with 1250 packages, even if half
> of them consist of single files.

I'm afraid so, indeed.

> One issue with this approach is that the package selection mechanism
> doesn't recognize the modules as being installed, or provide any assistance
> in selectively activating modules.

Indeed, since the selective activation relies crucially on the
`load-path` for that.

> Other places where there is a noticeable slowdown with large numbers of
> packages:
>   * Browsing customization groups - just unfolding a single group can take
> minutes (this is on fast server hardware with a lot of free memory)

Hmm... can't think of why that would be.  You might want to make
a separate bug-report for that.

>   * Browsing custom themes with many theme packages installed
> I haven't gotten to the point that I can test the same situation by
> explicitly loading the same modules from the site-lisp directory that had
> been activated as packages.  Installing the themes in the system directory
> does skip the "suspicious files" check that occurs when loading them from
> the user configuration.

Same here.  I'm not very familiar with the custom-theme code, but it
does seem "unrelated" in the sense that I don't think fixing some of the
other problems you've encountered will fix this one.

>> I think you're right here, but I'd expect the effect to be fairly small
>> except when the .elc/.eln files are themselves small.
> There are a lot of packages that have fairly small source files, just
> because they've factored their code the same way it would be in languages
> where the shared libraries are not in 1-1 correspondence with source files.

Oh, indeed, small source files are quite common.

> I would expect this would apply to most top-level defuns in elisp
> packages/modules.  From my cursory review, it looks like the ability to
> redefine these defuns is mostly useful when developing the packages
> themselves, and "sealing" them for use would be appropriate.

Advice are not used very often, but it's very hard to predict on which
function(s) they may end up being needed, and sealing would make advice
ineffective.  I would personally recommend to just stay away from the
level 3 of the native compiler's optimization.  Or at least, only use it
in targeted ways, i.e. only at the very rare few spots where you've
clearly found it to have a noticeable performance benefit.

In lower levels of optimization, those same calls are still optimized
but just less aggressively, which basically means they turn into:

    if (<symbol unchanged)
       <call the C function directly>;
    else
       <use the old slow but correct code path>;


        Stefan