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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>>> That's cheap: you can do it with linear allocation out of an array.
>>> Why would that be expensive?
>> That's very expensive compared to doing nothing.
>> It means that you have to allocate a new array, 
> Once.

No, what I describe is what happens every single time you go from one
side of the fence to the other (i.e. when Elisp calls to an external
module, as well as every time that external module does a funcall to an
Elisp function).

>> loop through the old one calling your "cheap allocation" function on
>> each element, instead of just passing the array pointer untouched.
> It's a pointer comparison of something that will be in L1 cache anyway.

What pointer comparison?  I'm talking about an allocation of an
array (one element per argument of the function being called) plus
a loop through this array.

> Of course it's slower than doing nothing. But you have not demonstrated
> that it is meaningfully slower,

We're talking about the building blocks of a language construct.

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

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

Using "Lisp_Object = emacs_value" lets us get a bit closer to
this ideal, tho.

> meanwhile, you're ignoring the compatibility benefits and consigning
> everyone to stack scanning forever.

I don't foresee any disappearance of stack-scanning in the next ten
years.  And any such disappearance if it ever happens will have much
further reaching consequences on Emacs's C code, so we'll be *thrilled*
to break backward compatibility for external modules at that point.


        Stefan