Re: [Emacs-diffs] emacs-25 3eb93c0: Rely on conservative stack scanning to find "emacs_value"s

[Stefan Monnier]

>> We're talking about the building blocks of a language construct.
> My point stands. I can't think of a real-world application of modules
> where the extra cycles matter.

How 'bout a module which implements an LALR parser and hence makes
repeated "module_funcalls" to an Elisp primitive that reads the next character?
The overhead of the call itself compared to the work done in that call
is likely to be very important to the overall performance.

>> There's no reason why a funcall from a module to an Elisp function (or
>> vice versa) should be significantly slower than if it were implemented
>> "in core".
> It's going to be slower no matter what due to the indirection through a
> function pointer.

A bit slower, yes, it's indeed inevitable.  But we should strive to get
as close as possible to that ideal.

>> Currently we're still pretty far from this ideal, because of the
>> signal-catching (which additionally forces us to allocate+fill+pass
>> a whole new "struct emacs_env_25" every time, instead of passing it once
>> and for all when opening the module).
> Are we? If so, that's a bug. We be reusing this structure. We shouldn't
> incur a penalty any more severe than setjmp, which in my benchmarks is
> very fast.

Look at the code, it calls initialize_environment right there in
Finternal_module_call.

> Emacs may end up moving to another VM, and that VM may very well do
> precise GC.

Sure.  I still predict that if we do switch to another VM, backward
compatibility of external modules because "emacs_value == Lisp_Object"
rather than "emacs_value == Lisp_Object*" will be the least of
our concerns.


        Stefan