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.
Yes, I agree. As I wrote in the initial email, my questions are primarily
curiosity about how the new capability can be further exploited. When I'm not
loading the build down with a ridiculous number of packages, it performs very well.
> 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's a good question - it was one of the articles I read when I first learned
about this new capability. It was in the context of overall emacs performance
with the feature enabled, rather than any particular piece of code.
> 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.
Chromium came to mind primarily because I've been tracking V8's refactoring
of the "Oilpan" gc for use as a stand-alone collector for other projects I'm interested in.
Though I believe V8 uses a type-tagging system treated specially by the collector separately
from the C++ classes managed by the stand-alone collector. That's the piece I think would
be adapted for lisp GC, with the added benefit of offering integrated GC for types using the
cppgc interface for additional modules.
I did see a thread in the archives of emacs-devel that someone hacked spider monkey's
collector a few years ago (2017 I believe) into emacs as a proof of concept. My very cursory
inspection of the memory allocation bits of the emacs core give me the impression the abstraction
boundaries set by the simple interface are not rampantly violated. I would hope that at this
point adapting the V8 (or similar) collector would be more straightforward than that effort was.
I'm also not sure whether code derived from V8 would be eligible for incorporation into emacs directly, given
the legal requirements for explicit copyright assignment. Maybe the best bet would be to define a
rigorous interface and allow alternative GC implementations to be plugged in. That would make it easier
to experiment with alternative garbage collectors more generally, which would probably be a general positive
if you were looking to improve that part of the system in general while maintaining the current safe implementation.
Lynn