Re: native compilation units

[Stefan Monnier]

> Not sure if these general statistics are of much use, but of 4324 source
> files successfully compiled (1557 from the lisp directory), with a total
> size of 318MB, including 13 trampolines,
> The smallest 450 are 17632 bytes or less, with the trampolines at 16744
> bytes, total of 7.4M
> The smallest 1000 are under 25700 bytes, totaling 20M
> The smallest 2000 are under 38592 bytes, totaling 48M
> The smallest 3000 are under 62832 bytes, totaling 95M
> The smallest 4000 are under 188440 bytes, totaling 194M
> There are only 58 over 500k in size, and only 13 over 1M (max is 3.1M)
> Those last 58 total about 52M in size.

The way I read this, the small files don't dominate, so bundling them
may still be a good idea but it's probably not going to make
a big difference.

> I am curious as to why the system doesn't just produce trampolines for all
> the system calls AOT in a single module.

Trampolines are needed for any native-compiled function which
gets redefined.  We could try to build them eagerly when the
native-compiled function is compiled, and there could be various other
ways to handle this.  There's room for improvement here, but the current
system works well enough for a first version.

> True, but it does lead to a little more disappointment when that 2.5-5x
> speedup is dominated by the load-path length while starting up.

I don't know where you got that 2.5-5x expectation, but native
compilation will often result in "no speed up at all".

> That would explain the behavior I've seen.  If that's the case, shouldn't
> batch-native-compile produce the byte-compiled file if it doesn't exist?

Sounds about right, tho maybe there's a good reason for the current
behavior, I don't know.  Maybe you should `M-x report-emacs-bug`.

> Sorry, no.  I meant I'm curious if having them in the user's cache versus
> the system ELN cache would make any difference in start-up time, ignoring
> the initial async native compilation.  In particular whether the checksum
> calculation is bypassed in one case but not the other (by keeping a
> permanent mapping from the system load-path to the system cache, say).

No, I don't think it should make any difference in this respect.

> I'm guessing the native compiled code is making the GC's performance a more
> noticeable chunk of overhead.

Indeed, the GC is the same and the native compiler does not make many
efforts to reduce memory allocations, so fraction of time spent in GC
tends to increase.

> I'd really love to see something like Chromium's concurrent gc
> integrated into Emacs.

Our GC is in serious need of improvement, yes.  Bolting some existing GC
onto Emacs won't be easy, tho.

> If I do any rigorous experiments to see if there's anything resembling a
> virtuous cycle in larger compilation units + higher intraprocedural
> optimizations, I'll report back.

Looking forward to it, thanks,

I'd be interested as well in seeing a `profile-report` output covering
your minute-long startup.


        Stefan