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

[Daniel Colascione]

On 04/01/2016 03:46 PM, Stefan Monnier wrote:
>>> 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.

You shouldn't have to talk to lisp to read buffers. Even if you wanted
to talk to lisp for it, you could batch requests and returning the next
N characters, amortizing the overhead.

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

On several occasions, you've mentioned that a VM move would be a
compatibility flag day for modules no matter what. I don't see why you'd
say so. The module API under discussion could be implemented equally
well by guilemacs today.

signature.asc
Description: OpenPGP digital signature